[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 08:17, Tim Johansson <email@example.com> wrote:
> On 2010-05-24 15:25, Kenneth Russell wrote:
>> I suggest that the best path forward might be to leave the signatures
>> of the texImage2D and texSubImage2D helpers taking DOM elements as
>> they are currently. Not adding an internalformat argument would make
>> it easier to add overloads later which have either this argument or
>> both internalformat and type arguments.
Not adding something now makes it easier to add it later... hmm I'm
not sure to follow the logic but why procrastinate then ? ;-)
Not having both parameters now will make the API more complex later
(twice many overloads at least), it was one of the initial starting
point of the discussion, all of the points discussed by Chris, X3D
guys or myself got completely discarded by the single issue over
"luminance vs grayscale" alone whereas this latter issue is just a
specification detail to sort out imho (something that has been sorted
out in GL already... ;-) ).
Ironically without these bridging actual web content in WebGL is less
efficient and much less flexible than bridging specially crafted
binary content from ArrayBuffers...
In my use case, involving two-way porting, I would really really much
prefer the API to provide exactly same signature as ES except for what
can be inferred from the DOM element (width, height, format), treating
the HTMLImageElement type as an opaque type that gets the colors bits
as needed (exactly like in native code you can ask libpng or whatever
to give you only the bits you need before passing them to texImage2D)
... this brings many porting and optimization opportunities that
aren't otherwise possible if we go with a limited API like the current
>Tightening up the spec to ensure compatibility is IMO far more important than saving memory, so I'm fine with just doing that for now.
I'm sure we can sort out the compatibility issues with careful
thinking and - more importantly - testing, we've discussed already
how to tentatively solve potential compatibility issues with
render-to-texture... I'm sure we can work out other issues we can
find, if any.
Having sub-optimal implementations for a while is one thing (could
default to RGBA for everything), having an API that _prevents_ apps
and implementations to use smarter optimizations when possible is
Also performance on embedded devices depends quite a bit on these
memory savings... this can be a make-or-break for WebGL apps using
more than a few low-res textures on ES :-(
> The question is then, do we spec it as always RGBA or RGB/RGBA depending on the presence of alpha?
Yeah since we'll need to spec DOM-to-texture conversion a minimum
there is even less reason to procrastinate and not make the little
step forward to make WebGL much _easier_ to use _efficiently_, with
all kinds of one-component masks and textures that do not need alpha
, without forcing developers to write and use inefficient
workarounds based on non-web formats (as decoding PNG/JPG directly in
ArrayBuffers and so on... this adds inefficiency and complexity in
application code and requires development/usage of specialized asset
In the hope to advance this discussion forward based on actual testing
and demonstrable behavior rather than vague fears, I've written a
Firefox early prototype implementation for the proposed spec for
DOM-to-texture  with both internalformat AND type argument, patch
and demo available here :
The patch currently uses by default automatic selection depending on
the DOM source image format and UNSIGNED_BYTE type, on the current
signatures used in current WebGL apps, I have yet to see any
incompatibility with on many WebGL demo I tried... need to write some
tests for the render-to-texture issues discussed with Tim earlier
though, as there is no demos that I know of using this feature yet.
Interestingly, the part of the implementation that caused me the most
difficulty and bugs wasn't the conversions themselves but the overload
resolution in the quick stub generation code ;o)
On average WebGL content is now using 15-25% less texture memory on
current content - not bad, especially considering that by above
definition current content only uses the minimal optimization possible
(e.g no UNSIGNED_SHORT_565).
 : or need to ALPHA of the same image in a different texture for
dynamic multi-texturing tricks in shaders etc...
 : http://neonux.com/webgl/conversions.html
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: