RE: [Canvas] proposal for supportsContext

Hi Dean,

this looks like a reasonable proposal.
Is there an expectation that the feature tests if a canvas of a particular size can be created?

If not, it's probably better to make the method static, like so:

interface HTMLCanvasElement : HTMLElement {
  static boolean supportsContext(DOMString contextId, any... arguments);
};

Otherwise you have to create a canvas object just to see if you can create a context.

Rik
________________________________________
From: Dean Jackson [dino@apple.com]
Sent: Monday, September 10, 2012 11:11 AM
To: public-html@w3.org
Subject: [Canvas] proposal for supportsContext

I propose adding a new method to HTMLCanvasElement:

interface HTMLCanvasElement : HTMLElement {
  boolean supportsContext(DOMString contextId, any... arguments);
};

supportsContext takes the same parameters as getContext, and simply returns
true if the corresponding call to getContext would have returned a valid
context, false otherwise.

The justification for this method is that it is sometimes expensive to create a
context. Many authors test for a canvas feature by trying to create a context,
examining the return value, and doing something different if the context was
null. This is ok in most cases, but there are some instances where we don't
want to create a context unless the page is really going to make use of it.

To give a real world example, the popular tool Modernizr tests for the
availability of WebGL by attempting to create a WebGL context. This can happen
even on pages that have no intention of using WebGL - an author has just
inserted Modernizr into their page and is using it to test for another feature.
As I said, creating a context is not a free operation. In fact, on shipping
Safari (Mountain Lion) this causes us to switch to a more powerful GPU
on systems that have two graphics processors.

An alternative (for the WebGL case) would be to have the author test for the
presence of window.WebGLRenderingContext. However, this is not reliable. We may
ship a browser that supports WebGL, but not on the particular hardware
configuration that the user is running. Or it could be a momentary
unavailability. There are a number of visible top-level WebGL apis, and we
don't want to have to hide/show them all based on availability.

Dean

Received on Tuesday, 11 September 2012 20:46:43 UTC