[Public WebGL] TexImage2D with no WebGLArray

Gregg Tavares [email protected]
Wed Jan 13 11:21:30 PST 2010


On Wed, Jan 13, 2010 at 11:13 AM, Kenneth Russell <[email protected]> wrote:

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

I must be reading different docs

http://www.opengl.org/wiki/Floating_point_and_mipmapping_and_filtering
http://www.opengl.org/registry/specs/ARB/texture_float.txt

These both define new internal format enums for floating point textures.





>
> 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/1dce4387/attachment.html>


More information about the public_webgl mailing list