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

Re: [Public WebGL] TexImage2D with no WebGLArray





On Wed, Jan 13, 2010 at 11:13 AM, Kenneth Russell <kbr@google.com> wrote:
On Thu, Jan 7, 2010 at 2:24 PM, Gregg Tavares <gman@google.com> wrote:


On Thu, Jan 7, 2010 at 2:11 PM, Chris Marrin <cmarrin@apple.com> 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