[whatwg] [canvas] getContext & multiple contexts

[Chris Marrin]

On Aug 2, 2010, at 3:16 PM, Ian Hickson wrote:

> 
> On Thu, 29 Apr 2010, Vladimir Vukicevic wrote:
>> 
>> A while ago questions came up in the WebGL WG about using a canvas with 
>> multiple rendering contexts, and synchronization issues that arise 
>> there. Here's our suggested change to getContext.
> 
> This seems overly complex. I've gone for a somewhat simpler approach, 
> which basically makes <canvas> fail getContext() if you call it with a 
> context that isn't "compatible" with the last one that was used, as 
> defined by a registry of contexts types. Currently, only '2d' and '3d' are 
> defined in this registry, and they are not defined as compatible.

'3d'? We're calling it 'webgl'. Is there another 3D context registered somewhere? I don't have a problem with this simplification.

> 
> 
>> It essentially allows for multiple contexts but adds no synchronization 
>> primitives other than the requirement that rendering must be visible to 
>> all contexts (that is, that they're rendered to the same destination 
>> space).
> 
> Having 3D and 2D contexts rendering to the same space -- especially given 
> getImageData() and the like -- seems like an interoperability nightmare.

I agree.

> 
> 
>> This also adds the 'attributes' parameter which can customize the 
>> context that's created, as defined by the context itself.  WebGL has its 
>> own context attributes object, and I'd suggest that the 2D context gain 
>> at least an attribute to specify whether the context should be opaque or 
>> not; but that's a separate suggestion from the below text.
> 
> I haven't added this. Could you elaborate on why this is needed? What 
> happens if the method is invoked agains with different parameters?
> 
> It seems far preferable to have this on the API rather than as part of the 
> getContext() method.

We feel it's more appropriate on the getContext() call because it involves creation of the resources for the context. If it were a separate call, you'd need to defer creation of those resources until the attribute call is made or create them as needed. This not only involves overhead in every call, but it requires you to provide specific rules on which calls cause automatic resource creation. Making it a parameter to getContext simplifies the definition. And it seems this would be a useful parameter for many types of contexts, even the 2D context as Vlad pointed out.

-----
~Chris
cmarrin at apple.com