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

Re: [Public WebGL] WebGLExtension interface proposal

Hi Chris!

On Sat, Jun 12, 2010 at 04:49, Chris Marrin <cmarrin@apple.com> wrote:
> I think we may have discussed this and rejected it as not being necessary. I may even have been an advocate of this approach but was convinced that such arbitrary base classes are unnecessary. But I may be confusing this issue with another similar one.

I agree this might not be necessary in Javascript, however this would
really simplify stronger-typed bindings where 'object' are to be
avoided whenever possible.

> Even if we did have a base class for extensions, I would not want it to be derived from WebGLObject. That base interface has a very specific meaning as the WebGL realization of the OpenGL Object concept. An extension is not part of that concept, so it would be inappropriate for it to be in that class hierarchy.

I agree the extensions are not really part of that concept in the
current revision of the spec, however I think we had a consensus
before to do the following change (which hasn't been acted upon in the
spec yet) :

* in 5.16.1 WebGLContextLostEvent:
"Once the context is reset, the application must reinitialize the
context's state and recreate all of its WebGL resources such as
textures, shaders and programs."

"Once the context is reset, the application must reinitialize the
context's state and recreate all of its WebGL resources such as
textures, shaders, programs and extensions.
The set of extensions returned by getSupportedExtensions() is not
guaranteed to be the same when the context is resumed, the application
must test and enable each supported extension individually again."

(from original message in thread "Addition to WebGLContextLostEvent
wrt extensions")

With that addition in mind I assume the concepts are very related :
boxed WebGL objects that are acquired and valid only within the same
context and within the same lifetime (before context loss), extension
objects fit that model.

> I don't see a need to expose the extension name in this interface. We don't expose identifications like this for any other object types in WebGL. I am comfortable with the interface returned by each extension being unique and unrelated to the others.

Okay, we can do without 'name' attribute, no strong opinion on that,
my intent was to avoid the 'empty' extension object behavior in some

>> Possibly we might as well simplify API and merge all is* functions into only one, e.g a probably better named "GLboolean isValid(WebGLObject object)".
>> (all current is* functions can trivially be wrapped to use it in Javascript so there is no feature removal and/or divergence imho)
> I don't think this is a good idea for similar reasons.

On the other hand, we already did similar thing with all
getString/getBoolean/getFloat/getInteger functions merged into
getParameter ... in OpenGL the typed versions of every function
(IsTexture, IsShader, ...) are necessary because the names are just
plain integers, so indeed an integer does not have to be a texture,
shader, whatever, or even the same integer could be both a texture and
a shader for instance.

In WebGL they are boxed typed objects... from an API discoverability
perspective it is confusing imho to have a signature IsTexture that
takes a WebGLTexture object as parameter... it looks like a helper for
(obj instanceof WebGLTexture) but this is not what it is about, a
isValid/IsAlive(WebGLObject) function would make the intent of the
function clearer, removing that confusion and making our API leaner
imho (including when we add other objects later, e.g WebGLQuery
someday probably).


You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email: