[Public WebGL] getContext multiple context language

Vladimir Vukicevic [email protected]
Mon Jan 25 13:44:57 PST 2010

On 1/23/2010 10:31 AM, Philip Taylor wrote:
> On Sat, Jan 23, 2010 at 1:45 AM, Vladimir Vukicevic
> <[email protected]>  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
> contextId.

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
>> CanvasRenderingContext2D.
> 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
>> INVALID_STATE_ERR exception.
> 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
> here.

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

     - Vlad
You are currently subscribe to [email protected]
To unsubscribe, send an email to [email protected] with
the following command in the body of your email:

More information about the public_webgl mailing list