[Public WebGL] TexImage2D with no WebGLArray

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


On Wed, Jan 13, 2010 at 11:21 AM, Gregg Tavares <[email protected]> wrote:

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

Those are the desktop specs. You need to look at

http://www.khronos.org/registry/gles/extensions/OES/OES_texture_float.txt

Note that it does not define any new internal formats. It only specifies
that HALF_FLOAT_OES and FLOAT are accepted as the <type> parameter to
TexImage2D, etc.

-Ken



>
>
>
>
>
>>
>> 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/125b3c28/attachment.html>


More information about the public_webgl mailing list