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

Re: [Public WebGL] isBuffer, isTexture etc.





On Fri, Apr 23, 2010 at 11:16 AM, Kenneth Russell <kbr@google.com> wrote:
On Fri, Apr 23, 2010 at 12:59 AM, Tim Johansson <timj@opera.com> wrote:
> On 2010-04-22 19:45, Gregg Tavares wrote:
>>
>> So it apparently turns out that the namespaces for GL objects are not
>> shared.
>>
>> In other words,  glIsBuffer does not tell you whether or not some name is
>> a buffer. It tells you whether or not a buffer exists with a specific id.
>>  The difference is subtle but what it means is 2 resources of different
>> types can have the same name.
>>
>> Try this out in C
>>
>> glBindBuffer(GL_ARRAY_BUFFER, 1);
>> glBindTexture(GL_TEXTURE_2D, 1);
>>
>> printf ("is buffer: %d\n", glIsBuffer(1));   // prints 1
>> printf ("is texture: %d\n", glIsTexture(1));  // prints 1
>>
>> That means the following WebGL functions
>>
>>     GLboolean isBuffer(in WebGLObject buffer) raises(DOMException);
>>     GLboolean isFramebuffer(in WebGLObject framebuffer)
>> raises(DOMException);
>>
>>     GLboolean isProgram(in WebGLObject program) raises(DOMException);
>>     GLboolean isRenderbuffer(in WebGLObject renderbuffer)
>> raises(DOMException);
>>     GLboolean isShader(in WebGLObject shader) raises(DOMException);
>>
>>     GLboolean isTexture(in WebGLObject texture) raises(DOMException);
>>
>> Should be changed to take their respective types as in
>>
>>     GLboolean isBuffer(in WebGLBuffer buffer) raises(DOMException);
>>
>>     GLboolean isFramebuffer(in WebGLFramebuffer framebuffer)
>> raises(DOMException);
>>     GLboolean isProgram(in WebGLProgram program) raises(DOMException);
>>     GLboolean isRenderbuffer(in WebGLRenderbuffer renderbuffer)
>> raises(DOMException);
>>
>>     GLboolean isShader(in WebGLShader shader) raises(DOMException);
>>     GLboolean isTexture(in WebGLTexture texture) raises(DOMException);
>>
>> In the WebGL case they would only return false after delete has been
>> called for the particular object.
>>
> I think it should also return false if the object is created by another
> WebGL context, since that would mean the object is not valid for the context
> on which is* was called.

It will today, but when sharing of resources between contexts is
supported in WebGL, then a texture created by one context may be valid
in another.

> Example
>  var t = ctx1.createTexture();
>  ctx1.isTexture(t); // true
>  ctx2.isTexture(t); // false
>
> If the calls does not do type checking calling isTexture with a framebuffer
> object would throw an error instead of returning false, but I don't really
> think it will be common to not keep track of the object types and rely on
> isTexture etc anyway so it's probably not a problem.

I'm in favor of leaving the signatures as they are and adding a type
check in the implementations. Web IDL would require a TypeError to be
raised in _javascript_ if they are more strongly typed and an object of
the wrong type is passed in. Currently the WebGLRenderingContext
reports most of its errors using OpenGL-style mechanisms (i.e.,
generating OpenGL errors rather than throwing _javascript_ exceptions).


I disagree.  By that argument ctx.bindTexture should be ctx.bindTexture(in GLenum target, in WebGLObject texture)


 
-Ken

> //Tim
>
> -----------------------------------------------------------
> 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:
>
>

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