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

Re: [Public WebGL] getContext multiple context language

On Sun, Feb 14, 2010 at 9:53 PM, Mark Callow <callow_mark@hicorp.co.jp> 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*?
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.

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?

Regards

    -Mark

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:callow_mark@hicorp.co.jp
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