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

Re: [Public WebGL] getContext multiple context language

On 1/23/2010 10:31 AM, Philip Taylor wrote:
On Sat, Jan 23, 2010 at 1:45 AM, Vladimir Vukicevic
<vladimir@mozilla.com> wrote:
object getContext(in DOMString contextId, in optional object attributes)
Perhaps this could use "in any... attributes" to be consistent with
toDataURL, with the interpretation of the attributes (number and type)
left entirely to the spec that defines behaviour for the given

any works for me.

'contextId' must be a string naming a canvas rendering context to be
returned. This specification only defines one context, with the name "2d".
If getContext() is called with that exact string for its 'contextId'
argument, then the UA must return a reference to an object implementing
This conflicts with the requirement later that it can return null,
e.g. if someone called getContext('3d') earlier.

Hm, yeah, the wording needs to be tightened up.

If getContext() is called multiple times on the same canvas with the same
context ID, it must return the same resulting context object provided that
the attributes are identical to all previous requests for that context ID.
If the attributes are not identical, getContext() must raise an
What does this mean? E.g. which of the following are errors:

   var a = { x: 1 }, b = { x : 1 }; // a != b
   c.getContext('example', a);
   c.getContext('example', b);

   var a = { x: 1 };
   c.getContext('example', a);
   a.x = 2;
   c.getContext('example', a);

   var a = { get x() { return Math.random(); } };
   c.getContext('example', a);
   c.getContext('example', a);

I don't see how it's possible to define a sensible notion of
"identical" for arbitrary JS objects. Maybe it'd be fine to simply
ignore attributes for all but the first call - that should be simple
to define and to implement interoperably, and I don't imagine this
would be a common or hard-to-debug authoring error. (Browsers could
emit warnings in their error consoles anyway, saying they're ignoring
the changed attributes, if it turns out to be a common mistake.)

It should really say "provided that the canvas determines that the requested attributes are identical". That is, the object itself doesn't have to be identical, but the meaning should be. One tricky thing is specifying what should happen when a context doesn't understand an attribute -- is that an error, or should it be ignored? If it's ignored, that's helpful for forwards-compat, but it means that the context must have a way to query the current attributes to inspect what it actually got.

So maybe this means that we need an 'any getContextAttributes(in DOMString contextID);' method, that will return the actual set of attributes active for the given context? (Or throw an error if the given contextID isn't active on this canvas.)

I don't really like the idea of getContext ignoring attributes on subsequent invocations; it seems like it would potentially lead to weird situations that we should avoid.

If getContext() is called with a context ID different from the context IDs
given to any previous successful calls to getContext(), it may either return
a new canvas context that can be used simultaneously with all previously
obtained contexts, or return null to indicate that the newly requested
context cannot be used with the previously obtained contexts.
What is a successful call? If getContext returns null because it
doesn't support simultaneous rendering, is that a successful call?

Sounds like I need to introduce some language defining an "active" context, to remove that confusion... this really means "a getContext call which resulted in a non-null return value".

If multiple rendering contexts are active, they all render to the same
canvas; they are not layered or otherwise isolated. Changes made to the
canvas with one context must be immediately visible to any other active
contexts on the canvas.
The first two mentions of "canvas" should be "bitmap", to make it
clear they're really talking about the bitmap that's associated with
the canvas.

Will do.

It is up to the implementation to manage
synchronization issues associated with rendering with different contexts to
the same canvas.
I assume the original spec's paragraphs on vendorname-context and on
returning null for unrecognised contexts should still be included

Yep. Thanks for the feedback! I'll post updated language shortly.

    - Vlad
You are currently subscribe to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email: