[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 2:26 PM, Chris Marrin <cmarrin@apple.com> wrote:

On Jan 13, 2010, at 11:39 AM, Kenneth Russell wrote:

> On Wed, Jan 13, 2010 at 11:21 AM, Gregg Tavares <gman@google.com> wrote:
>
>
> 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.
>
> 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.

I'm confused. I think the proposal is to have one form of texImage2D with format, type and pixels params, and another without. If you use the first form, you can use it to pass in a floating point texture, if and when we support it, right? If you use the second form, you're just setting up a texture with a given size and no contents (it would be set to transparent black or its equivalent, I think). Then you'd use texSubImage2D, which has the same type and format params, to load the values, which could be floating point if supported.

Is that wrong?

What's wrong is that unlike Desktop GL, OpenGL ES uses some of those other parameters to decide the internal format. 

void glTexImage2D(
     GLenum target,
     GLint level,
     GLint internalformat,   // In desktop GL only this decides the internal format
     GLsizei width,
     GLsizei height,
     GLint border,
     GLenum format,     
     GLenum type,        // in GL ES, this is also used to decide the internal format.
     const GLvoid * data);

Given that's the case there's no reason to have the extra overload I was suggesting.




-----
~Chris
cmarrin@apple.com




-----------------------------------------------------------
You are currently subscribe to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email: