[Public WebGL] TexImage2D with no WebGLArray

Gregg Tavares [email protected]
Wed Jan 13 14:46:44 PST 2010


On Wed, Jan 13, 2010 at 2:26 PM, Chris Marrin <[email protected]> wrote:

>
> On Jan 13, 2010, at 11:39 AM, Kenneth Russell wrote:
>
> > 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.
>
> 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
> [email protected]
>
>
>
>
> -----------------------------------------------------------
> You are currently subscribe to [email protected]
> To unsubscribe, send an email to [email protected] with
> the following command in the body of your email:
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20100113/01712f04/attachment.html>


More information about the public_webgl mailing list