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

Re: [Public WebGL] isBuffer, isTexture etc.

On Thu, Apr 22, 2010 at 4:29 PM, Oliver Hunt <oliver@apple.com> wrote:

Yes, I see where the OpenGL definition is different than what we've been assuming. But I'm note sure we should change the API. If we leave it as is, the functions will perform as you say. A deleted object will return false. But it will also perform the additional task of type checking. So you can ask, "is this object a valid FrameBufferObject?" which will only return true if the object is actually a FrameBufferObject AND it hasn't been deleted. That seems like useful and non-harmful functionality.

Except it's duplicated. You can already check the type of an object in language standard ways can't you?

if (myObject instanceof WebGLTexture) { ... }

If I have two frames, and send a WebGLTexture from one frame to another that check will fail, as the instanceof check depends on exact equality and each global object has a different copy of the WebGLTexture constructor object.  ES5 actually added an Array.isArray function to deal with this problem.

is nicer than
 ... (myObject instanceof WebGLTexture) && context.isTexture(myObject)

Also the required type checks can be done vastly faster in the implementation than in JS.

I guess I don't see the point. What app doesn't know what its resources are ... and... why the special treatment of WebGL objects vs every other object in his app?

On top of that it's misleading if you ever go use OpenGL because the behavior will not match OpenGL.