[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] Adding internalformat param to all texImage2d variants

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 :


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.

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: