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 :
> 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.
> On Wed, May 26, 2010 at 17:37, Cedric Vivier <firstname.lastname@example.org> wrote:
>> On Tue, May 25, 2010 at 21:54, Cedric Vivier <email@example.com> 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 firstname.lastname@example.org.
> To unsubscribe, send an email to email@example.com with
> the following command in the body of your email: