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

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



FYI: the WebGL working group met in Mountain View over the past two
days and there was agreement to:

 - Remove the flipY and asPremultipliedAlpha flags from the texImage2D
variants taking HTML elements and specify these as WebGL-specific
pixel store parameters instead.
 - Add all of the internalformat, format and type parameters to the
texImage2D variants taking HTML elements. For forward compatibility
all three are needed.

More information to be posted to the list in the coming couple of days
for discussion, but hopefully this will please most contributors to
this thread and ease concerns.

-Ken

On Wed, May 26, 2010 at 9:51 AM,  <tomi.aarnio@nokia.com> wrote:
> +1 from me too. Textures consume so much memory compared to everything else that developers really need the ability to control the format they´re stored in.
>
> FWIW, I also second the proposal to change the readPixels signature to better match its native counterpart. ReadPixels is generating massive amounts of garbage in its current form.
>
>  Tomi
>
>> +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:
>> >
>>
>>
>
> -----------------------------------------------------------
> 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:
>
>

-----------------------------------------------------------
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: