[whatwg] [canvas] getContext & multiple contexts

Vladimir Vukicevic vladimir at pobox.com
Thu Apr 29 08:44:44 PDT 2010


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.


More information about the whatwg mailing list