[Public WebGL] TexImage2D with no WebGLArray

Kenneth Russell [email protected]
Wed Jan 13 11:13:27 PST 2010


On Thu, Jan 7, 2010 at 2:24 PM, Gregg Tavares <[email protected]> wrote:

>
>
> On Thu, Jan 7, 2010 at 2:11 PM, Chris Marrin <[email protected]> wrote:
>
>>
>> On Jan 7, 2010, at 1:05 PM, Gregg Tavares wrote:
>>
>> > TexImage2D currently has 4 overloads. I was wondering if it should have
>> 1 more
>> >
>> > 3 of them take various HTML tags as input (img, canvas, video)
>> >
>> > The fourth one is taken from the original GL
>> >
>> > void texImage2D(in GLenum target, in GLint level, in GLenum
>> internalformat,
>> >                     in GLsizei width, in GLsizei height, in GLint
>> border, in GLenum format,
>> >                     in GLenum type, in WebGLArray pixels)
>> raises(DOMException);
>> >
>> >
>> > The last argument, pixels is allowed to be null but in the case where
>> it's null the 2 arguments before that, format and type, are irrelevant since
>> they define the format for the WebGLArray and yet you still have to pass
>> them and supposedly they still have to be valid enums.
>> >
>> > Instead of allowing pixels to be null, how about always requiring it and
>> then adding one more overload that doesn't have the last 3 arguments
>> >
>> > void texImage2D(in GLenum target, in GLint level, in GLenum
>> internalformat,
>> >
>> >                     in GLsizei width, in GLsizei height, in GLint
>> border) raises(DOMException);
>> >
>> > It's pretty minor but I just thought I'd ask.
>>
>> I think it's a good idea. In that case we'd disallow null in the first
>> form you show, right?
>
>
> Yes, we'd disallow null.
>
>
>> If no one objects by tomorrow, we should do it...
>>
>
After doing some more research there is a problem with this proposal. If we
ever want to support the OES_texture_float and OES_texture_half_float
extensions, which would be extremely useful for High Dynamic Range rendering
and other techniques, then it turns out the <type> parameter to texImage2D
is significant. These extensions do not add any new internal formats (like
GL_RGBA32F) to OpenGL ES 2.0; they only allow GL_FLOAT and GL_HALF_FLOAT_OES
to be used as the <type> parameter. Presumably the GL is supposed to infer
that the user wants floating-point rather than integer components for the
internal format they requested.

Given this fact I think we should leave the spec as it is. The other
alternative would be to provide desktop GL tokens like GL_RGBA32F in a
future version of the WebGL spec and emulate their behavior when running on
top of OpenGL ES 2.0 + extensions.

-Ken
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20100113/8a295793/attachment.html>


More information about the public_webgl mailing list