Re: [whatwg] [canvas] Proposal for supportsContext

Can't Modernizr just lazy load the WebGL context?  (i.e. only try to create
a context if the web page actually asks if WebGL is supported)

On the other hand I would love to see a supportsContext function which can
tell if WebGL is software rendered (i.e. Swiftshader in Chrome).  There's
been a lot of discussion about that and how to define it, but in our
experience 2D games rendered with Swiftshader are far slower than rendered
with a software-rendered 2D canvas.  We have production code in the wild
which detects Swiftshader by its supported WebGL extensions.  I'd love to
replace this even with something vendor specific, like:

canvas.supportsContext("webgl", { "-webkit-allowswiftshader": false })

Despite the hardness to define it, I do feel there is a practical need for

Ashley Gullen

On 10 September 2012 19:14, Dean Jackson <> wrote:

> I sent this to the list:
> Copied below.
> [[[
> 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 Monday, 10 September 2012 19:36:08 UTC