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

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



+1

As a developer I'd rather just specify the format explicitly.

-T

On May 26, 2010 11:47 AM, "Cedric Vivier" <cedricv@neonux.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
> 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.
>
>
> Regards,
>
>
> 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:
>