Re: [whatwg] [canvas] getContext multiple contexts
On Aug 3, 2010, at 3:41 PM, Ian Hickson wrote: On Tue, 3 Aug 2010, Chris Marrin wrote: 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? Sorry, typo in the e-mail. The spec correctly refers to a webgl context. (I have to say, I'd rather we called it 3d. I hate it when we embed marketing names into the platform.) I generally agree. For me, I consider WebGL to be a clarifying name like HTML, rather than a marketing name. [arguments on getContext] 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. What happens if you call getContext with the same contextID but different attributes? Good question. It's addressed in https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/doc/spec/WebGL-spec.html#2.1. It says that subsequent calls ignore the attributes. There is a getContextAttributes call on the context to return what attributes were actually set. - ~Chris cmar...@apple.com
Re: [whatwg] [canvas] getContext multiple contexts
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 cmar...@apple.com
Re: [whatwg] [canvas] getContext multiple contexts
On Aug 3, 2010, at 3:15 PM, Chris Marrin wrote: 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. Sorry, in rereading this I realize that the last statement is confusing. I don't have a problem with hixie's simplification on when to fail getContext. The string passed for a WebGL context should be 'webgl', not '3d'. - ~Chris cmar...@apple.com
Re: [whatwg] [canvas] getContext multiple contexts
On Tue, 3 Aug 2010, Chris Marrin wrote: 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? Sorry, typo in the e-mail. The spec correctly refers to a webgl context. (I have to say, I'd rather we called it 3d. I hate it when we embed marketing names into the platform.) [arguments on getContext] 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. What happens if you call getContext with the same contextID but different attributes? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [canvas] getContext multiple contexts
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. 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. 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. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] [canvas] getContext multiple contexts
Hey folks, 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. 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). 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. - Vlad object getContext(in DOMString contextId, in optional any attributes) A canvas may be rendered to using one or more contexts, each named by a string context ID. For each canvas, there is a set of zero or more active contexts. The getContext() method is used to obtain a particular rendering context for the canvas. 'contextId' must be a string naming a canvas rendering context to be returned. For example, this specification defines the '2d' context, which, if requested, will return either a reference to an object implementing CanvasRenderingContext2D or null, if a 2D context cannot be created at this time. Other specifications may define their own contexts, which would return different objects. The optional 'attributes' parameter must be either unspecified or an object specific to the context being requested. An unspecified value indicates a default set of attributes, as defined by the context ID. Unknown attributes must be ignored by the context. If getContext() is called with a context ID that the implementation does not support, it must return null. If there are no active contexts for the canvas, the implementation must create the specified context for the canvas. If a context ID that is already an active context for the canvas is requested, then any passed attributes must be ignored, and a reference to the existing context object must be returned. If there are one or more active contexts and a context ID that is not currently active is requested, it is up to the implementation to determine whether the requested context can be used simultaneously with all currently active canvas contexts. If simultaneous rendering with the requested context is not possible, getContext() must return null. Otherwise the implementation must create the specified context for the canvas. 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. If a new context is successfully created, a reference to an object implementing the context API is returned and the new context is added to the list of active contexts for the canvas. If multiple rendering contexts are active, they all render to the same canvas bitmap; they are not layered or otherwise isolated. Changes made to the canvas bitmap with one context must be immediately visible to any other active contexts on the canvas. The implementation must manage synchronization issues associated with rendering with different contexts to the same canvas. Supporting different rendering contexts within the same canvas is not recommended due to the significant cost of synchronization. Instead, each context API is encouraged to support generic interoperability with other canvases. For example, the 2D canvas API provides a drawImage method that can render the contents of another canvas.
