[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
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
as they see fit since there is no round-trip to/from JavaScript (which
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).
Automatic selection can be done in clever ways by JavaScript libraries
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 patch outputs a deprecation warning in the Javascript console when
the 'old' signature is used.


On Wed, May 26, 2010 at 17:37, Cedric Vivier <cedricv@neonux.com> wrote:
> On Tue, May 25, 2010 at 21:54, Cedric Vivier <cedricv@neonux.com> wrote:
>> Firefox early prototype implementation for the proposed spec for
>> DOM-to-texture [2] 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 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
> sense that automatic selection is handled by Javascript libraries
> 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
> be as expensive as decompressing whole file in JavaScript) to get such
> 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 public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email: