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

Re: [Public WebGL] WebGLExtension interface proposal



On Jun 11, 2010, at 11:22 PM, Cedric Vivier wrote:

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

Right, but a given language binding is free to add any sort of more strongly typed objects as needed. I think the reason for the existance of 'object' is to avoid the need of locking the API into a particular hierarchy unnecessarily. 

> 
> 
>> 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:
> replace:
> "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."
> 
> with:
> "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 think the concepts are that related. The WebGL objects represent actual GL resources. The extension objects just represent a wrapper around a capability. You restore WebGL objects because the GL objects they represent need to be reconstructed. The extension objects need to be restored because you may have a different set of extensions available. These are different concepts.

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

There are no empty objects, only empty <something clever> :-)

The very existence of an extension object is an indication of the availability and activation of that extension. That in and of itself is useful.

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

True and I'm not strongly opposed to this suggestion. I just don't think it's particularly helpful and makes the code a bit less readable. Unifying the get calls doesn't do damage because you pass a parameter indicating the information you want so good documentation is maintained. From a documentation standpoint I think 'isShader(myThing)' is better than 'isValid(myThing)'.

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

Yeah, true, and again, I'm not strongly opposed to it.

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