On Wed, Jan 13, 2010 at 11:21 AM, Gregg Tavares <span dir="ltr"><<a href="mailto:gman@google.com">gman@google.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br><br><div class="gmail_quote"><div class="im">On Wed, Jan 13, 2010 at 11:13 AM, Kenneth Russell <span dir="ltr"><<a href="mailto:kbr@google.com" target="_blank">kbr@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left:1px solid rgb(204, 204, 204);margin:0pt 0pt 0pt 0.8ex;padding-left:1ex">

<div>On Thu, Jan 7, 2010 at 2:24 PM, Gregg Tavares <span dir="ltr"><<a href="mailto:gman@google.com" target="_blank">gman@google.com</a>></span> wrote:<br></div><div class="gmail_quote"><div><blockquote class="gmail_quote" style="border-left:1px solid rgb(204, 204, 204);margin:0pt 0pt 0pt 0.8ex;padding-left:1ex">


<br><br><div class="gmail_quote"><div>On Thu, Jan 7, 2010 at 2:11 PM, Chris Marrin <span dir="ltr"><<a href="mailto:cmarrin@apple.com" target="_blank">cmarrin@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left:1px solid rgb(204, 204, 204);margin:0pt 0pt 0pt 0.8ex;padding-left:1ex">



<div><div></div><div><br>
On Jan 7, 2010, at 1:05 PM, Gregg Tavares wrote:<br>
<br>
> TexImage2D currently has 4 overloads. I was wondering if it should have 1 more<br>
><br>
> 3 of them take various HTML tags as input (img, canvas, video)<br>
><br>
> The fourth one is taken from the original GL<br>
><br>
> void texImage2D(in GLenum target, in GLint level, in GLenum internalformat,<br>
>                     in GLsizei width, in GLsizei height, in GLint border, in GLenum format,<br>
>                     in GLenum type, in WebGLArray pixels) raises(DOMException);<br>
><br>
><br>
> 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.<br>




><br>
> 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<br>
><br>
> void texImage2D(in GLenum target, in GLint level, in GLenum internalformat,<br>
><br>
>                     in GLsizei width, in GLsizei height, in GLint border) raises(DOMException);<br>
><br>
> It's pretty minor but I just thought I'd ask.<br>
<br>
</div></div>I think it's a good idea. In that case we'd disallow null in the first form you show, right?</blockquote></div><div><br>Yes, we'd disallow null.<br> </div><div><blockquote class="gmail_quote" style="border-left:1px solid rgb(204, 204, 204);margin:0pt 0pt 0pt 0.8ex;padding-left:1ex">



 If no one objects by tomorrow, we should do it...<br></blockquote></div></div></blockquote><div><br></div></div><div>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.</div>

</div></blockquote></div><div><br>I must be reading different docs<br><br><a href="http://www.opengl.org/wiki/Floating_point_and_mipmapping_and_filtering" target="_blank">http://www.opengl.org/wiki/Floating_point_and_mipmapping_and_filtering</a><br>

<a href="http://www.opengl.org/registry/specs/ARB/texture_float.txt" target="_blank">http://www.opengl.org/registry/specs/ARB/texture_float.txt</a><br><br>These both define new internal format enums for floating point textures.<br>
</div></div></blockquote><div><br></div><div>Those are the desktop specs. You need to look at</div><div><br></div><div><a href="http://www.khronos.org/registry/gles/extensions/OES/OES_texture_float.txt">http://www.khronos.org/registry/gles/extensions/OES/OES_texture_float.txt</a></div>
<div><br></div><div>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.</div><div><br></div><div>-Ken</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="gmail_quote"><div><br><br>
<br> </div><div class="im"><blockquote class="gmail_quote" style="border-left:1px solid rgb(204, 204, 204);margin:0pt 0pt 0pt 0.8ex;padding-left:1ex"><div class="gmail_quote">
<div><br></div><div>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.</div>


<div><br></div><div>-Ken</div><div><br></div></div>
</blockquote></div></div><br>
</blockquote></div><br>