[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] Adding internalformat param to all texImage2d variants
Demo and patch V2, not performing automatic selection :
Implementation is much refactored now, without automatic selection the
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,
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.
On Wed, May 26, 2010 at 17:37, Cedric Vivier <email@example.com> wrote:
> On Tue, May 25, 2010 at 21:54, Cedric Vivier <firstname.lastname@example.org> wrote:
>> Firefox early prototype implementation for the proposed spec for
>> DOM-to-texture  with both internalformat AND type argument, patch
>> and demo available here :
> 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 :
> This lesson shows a rotating earth with a specular map, with automatic
> 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 not
> 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" use
> 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 texture
> 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 they
> 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.
You are currently subscribed to email@example.com.
To unsubscribe, send an email to firstname.lastname@example.org with
the following command in the body of your email: