[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] Adding internalformat param to all texImage2d variants
+1 from me too. Textures consume so much memory compared to everything else that developers really need the ability to control the format they´re stored in.
FWIW, I also second the proposal to change the readPixels signature to better match its native counterpart. ReadPixels is generating massive amounts of garbage in its current form.
> As a developer I'd rather just specify the format explicitly.
> On May 26, 2010 11:47 AM, "Cedric Vivier" <email@example.com> wrote:
> > Demo and patch V2, not performing automatic selection :
> > http://neonux.com/webgl/dom-to-texture-v2.html
> > Implementation is much refactored now, without automatic selection the
> > signature :
> > texImage2D(target, level, internalformat, type, element)
> > essentially becomes a shorthand for Gregg's suggestion :
> > texImage2D(target, level, internalformat, element.width,
> > element.height, 0, internalformat, type,
> > element.getPixelsAsArrayBuffer(internalformat, type));
> > With the added benefit that considering a DOM element as an opaque
> > pixel bag does allow implementations to do any optimization in native
> > would be bad as Kenneth pointed out).
> > Without automatic selection we do not need to define default
> > DOM-to-texture formats at all (e.g RGBA or RGB), we make web
> > developers more careful (or even aware) about the choice of formats,
> > and we do not have any special case to handle for
> > framebuffers/renderbuffers as it is essentially just an efficient way
> > to upload pixels from an element, normal ES behavior applies, no
> > surprises! and easier porting to/from native ES).
> > if necessary - without not much performance cost this time - as they
> > can just infer from the element type, url, decoding header only, or
> > any application-specific differentiator, and even use a
> > HTMLImageElement.sourceFormat attribute if it available one day (as
> > Chris suggested iirc).
> > the 'old' signature is used.
> > Regards,
> > On Wed, May 26, 2010 at 17:37, Cedric Vivier <firstname.lastname@example.org>
> > > On Tue, May 25, 2010 at 21:54, Cedric Vivier <email@example.com>
> > > > Firefox early prototype implementation for the proposed spec for
> > > > DOM-to-texture  with both internalformat AND type argument, patch
> > > > and demo available here :
> > > >
> > > > http://neonux.com/webgl/dom-to-texture.html
> > >
> > > To follow-up about this, I've done a lot more tests since yesterday,
> > > there is use cases where the benefits are really significant (if 20%
> > > is not significant enough ;) ).
> > > For instance I've ported Learning WebGL's Lesson 15 to the new
> > > signature with internalformat and type :
> > >
> > > http://neonux.com/webgl/lesson15/
> > >
> > > This lesson shows a rotating earth with a specular map, with
> > > selection RGB is used for both color map and specular map (since both
> > > are indeed 3-component images), the lesson uses 3MB texture memory
> > > instead of 4MB (25% reduction).
> > > However since specular map is obviously a good candidate for using
> > > LUMINANCE and since the color map is not very high quality using
> > > type=UNSIGNED_SHORT_5_6_5 makes sense ; in this case texture memory
> > > usage goes from 4MB to only 1.5MB (65% reduction).
> > >
> > >
> > > Though this lesson is obviously not using mobile-optimized textures,
> > > realistically there will be a lot of WebGL content doing the same.
> > > Current WebGL on an ES device limited to 24MB texture memory would
> > > be even able to load and render the solar system since it would be
> > > able to store/render 5 planets only...
> > > With correct usage of format and type as above, it can render 14
> > > planets with textures of similar resolution (so the "solar system"
> > > case works even with a few asteroids here and there ;-) ).
> > >
> > >
> > > I'd like to say that by testing this on current content I'm realizing
> > > that we may be better off scraping automatic selection (ie. 0 /
> NONE /
> > > DONT_CARE) and force developers to use valid enums for internalformat
> > > and type as they would do with ArrayBuffer (or native ES actually).
> > > It simplifies the spec and implementations, but more importantly I
> > > believe it would make sense for general
> > > mobile-interoperability/friendliness of WebGL content that developers
> > > HAVE to think about the best format they should use depending what
> > > they want to do.
> > >
> > > WebGL being a low-level API closely related to ES 2.0, it would make
> > > directly, e.g a LIB.loadTexture(element) function would load a
> > > in RGB if element is a video or an image whose URL ends with ".jpeg".
> > > Later, such librarires could be more precise about this whenever they
> > > have a way to get the source format from a HTMLImageElement... or
> > > also could XHR peek and decode only the header of the file (would not
> > > information, and the heavy part (decompression and potential
> > > conversion of the element's data) would still be done efficiently by
> > > WebGL natively.
> > >
> > >
> > > Regards,
> > >
> > -----------------------------------------------------------
> > You are currently subscribed to firstname.lastname@example.org.
> > To unsubscribe, send an email to email@example.com with
> > the following command in the body of your email:
You are currently subscribed to firstname.lastname@example.org.
To unsubscribe, send an email to email@example.com with
the following command in the body of your email: