On Sun, Feb 14, 2010 at 9:53 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 returned.
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?
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*?
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.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.
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.
The latest draft of the WebGL spec says "On subsequent calls to getContext() with the ‘
begin:vcard fn:Mark Callow n:Callow;Mark org:HI Corporation;Graphics Lab, Research & Development adr:Higashiyama 1-4-4, Meguro-ku;;Meguro Higashiyama Bldg 5F;Tokyo;;153-0043;Japan email;internet:email@example.com title:Chief Architect tel;work:+81 3 3710 9367 x228 tel;fax:+81 3 5773 8660 x-mozilla-html:TRUE url:http://www.hicorp.co.jp, http://www.mascotcapsule.com version:2.1 end:vcard