[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 <email@example.com> wrote:
> Vladimir Vukicevic wrote:
>> Here's essentially Ken's changes plus a few sentences I added to the end
>> to try to make it clear that the multiple-context case is discouraged due to
>> the synchronization cost. I think this is good to go; I'll look at sending
>> it off to html5/webapps today or tomorrow.
>> 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. 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.
You are currently subscribe to firstname.lastname@example.org.
To unsubscribe, send an email to email@example.com with
the following command in the body of your email: