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

Re: [Public WebGL] WebGLExtension interface proposal



On Jun 8, 2010, at 12:05 PM, Cedric Vivier wrote:

> Hi,
> 
> We specify extensions as objects with more or less the same behavior as other WebGL objects mapped to GL resources, ie. an extensions object is only valid for use by the WebGLRenderingContext who created it and they should be re-created after context is lost ; as such I believe it would make sense to declare a WebGLExtension interface from which all WebGL extensions must derive.
> It could simplify implementations (can use the same base WebGLObject implementation for validation/tracking, extensions could also more easily use same base object for internal housekeeping), but more importantly it makes API friendlier to more strongly-typed languages (versus 'object'), avoids potential 'empty object extension' which might be confusing, and allows us to transparently add new 'utility' members on all extensions if we need to do so in a future revision.
> 
> In other words, I propose following spec addition :
> 
> 
> 5.XX WebGLExtension
> 
> The WebGLExtension interface represents an extension object. All WebGL extensions derive from this interface.
> The object is returned by calling getExtension with a supported extension string (see 5.16.14 Detecting and enabling extensions).
> 
> interface WebGLExtension : WebGLObject {
> 	readonly attribute DOMString name;
> }
> 
> 
> And :
> 
> WebGLExtension getExtension(DOMString name);
> 
> instead of :
> 
> object getExtension(DOMString name);

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.

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

> 
> 
> 
> Finally, for consistency with other WebGLObjects I propose introduction of an isExtension function to check if an extension
> object is valid (ie. not obtained from another context and not acquired before context loss) :
> 
> GLboolean isExtension(WebGLExtension extension);

Again, this is a convention used for WebGLObject derived interfaces. I don't see a reason to add extensions to  that mix.

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

-----
~Chris
cmarrin@apple.com





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