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

Re: [Public WebGL] Should WebGLContextAttributes be a callback interface?

On Sat, Mar 31, 2012 at 9:03 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

https://www.khronos.org/registry/webgl/specs/latest/#5.2 says yes.

https://www.khronos.org/registry/webgl/specs/latest/webgl.idl says no.

Is the mismatch expected?

The IDL is out of date.  It doesn't reflect the nullable changes made recently, either.

I'm not sure why this is declared as a callback interface. https://www.khronos.org/registry/webgl/specs/latest/#2.1 talks about using the options object passed to getContext to set up the WebGLContextAttributes, but that doesn't require the WebGLContextAttributes to be a callback interface.

The idea is that the object you pass to getContext *is* a WebGLContextAttributes, as if getContext's signature is WebGLContext getContext(DOMString contextId, WebGLContextAttributes attrs), so WebIDL takes care of type conversions for the members.

This could also be done by defining it as a WebIDL dictionary.  It would be unusual for getContextAttributes to return a WebIDL dictionary instead of an interface, and while it could define the type twice (as both a dictionary and an interface), I'm not sure that actually gains anything.

 Is the expectation that getContextAttributes will return the same object (when compared with === in JS, say) as was passed to getContext(), or a new object which only has the relevant attributes on it?

No, because getContextAttributes says "Returns a new WebGLContextAttributes object".
In any case, it seems like the attributes should be readonly, right?

Yeah, probably.

Glenn Maynard