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

Re: [Public WebGL] isBuffer, isTexture etc.



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).

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