[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] getContext multiple context language
On Tue, Feb 16, 2010 at 7:23 PM, Mark Callow <firstname.lastname@example.org> wrote:
Vladimir Vukicevic wrote:
Certain context types may not support all combinations of
context-specific attributes. If an unsupported set of attributes is
requested during context creation, but the context ID is otherwise
compatible with all existing contexts, then the implementation must
create the new context with a set of attributes that best satisfies
those requested. The caller is responsible for using context-specific
APIs to determine whether the attributes used to create the context
satisfy the requirements of the caller's code.
This opens the barn door far wider for applications to shoot themselves in
the feet (to work on one implementation and not on others) than possibly
omitted explicit synchronization calls to which vehement objections were
raised. I think requesting unsupported attributes should cause getContext to
return null or even throw an unsupported operation exception.
Having getContext return null or throw an exception in this case
causes asymmetry in the API's behavior. We have already decided that
if another library had previously created the (WebGL) context with a
specific set of attributes incompatible with the current set of
attributes being requested, the previously created context will be
The asymmetry comes from the decision to return an existing context,
even if the attributes are different. I don't know the use case for
this. Why would an application (a) request the context a second time on
the same canvas and (b) do so with different attributes?
An application might use two libraries, and each might request a context on the same canvas but request slightly different (but ultimately compatible) attributes.
By the way, I don't understand "all existing contexts" in the, er..,
context of the paragraph I quoted above from Vladimir. Doesn't
contextID refer to a context *type*?
Yes, contextID is a type of context, like "webgl". The "all existing contexts" means the contexts which have previously been created against the canvas. It might be the case that if you had previously created an "openvg" context that attempts to create a "webgl" context would fail.
This is basically the same situation as requesting a
specific set of unsupported attributes, like a stencil buffer but no
depth buffer. I don't think it is a good idea to fail to return a
context in the latter situation. Instead, the implementation should
make a best effort to satisfy the request (for example, providing both
a depth and stencil buffer) and let the application make sure in both
cases that the context's attributes are sufficient. This will unify
the application's code paths.
They'll be equally unified if we return null when the attributes don't
match what is supported at initial context creation or an existing
context of the requested type.
For the current set of WebGL context attributes, allowing the
implementation to make a best effort (meet or exceed the request) is
probably OK. But the language Vlad has proposed is for the HTML5 spec.
and will ultimately apply to many different context types. It is not
hard to imagine a set of attributes for some context type where meet or
exceed is not always possible.
Perhaps, although in my experience the OpenGL context attributes are quite complex compared to those of other contexts.
Regardless, I think we should standardize on "best match" behavior as it is the easiest for developers to work with. If it turns out to be undesirable for some other context type then they can use the other interoperability mechanisms of painting one canvas into another or uploading it as a texture.
The latest draft of the WebGL spec says "On subsequent calls to
getContext() with the ‘
webgl’ string, the
passed WebGLContextAttributes object, if any, shall be ignored." Is it
planned to change this if the Vlad's suggested language for getContext
is accepted by HTML5?
Yes, this will be superseded by the new text above, and the WebGL spec will point to the HTML5 language.