[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 <firstname.lastname@example.org>
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?