W3C home > Mailing lists > Public > whatwg@whatwg.org > September 2012

Re: [whatwg] [canvas] Proposal for supportsContext

From: Ashley Gullen <ashley@scirra.com>
Date: Mon, 10 Sep 2012 20:35:30 +0100
Message-ID: <CAABs73hy+JgGTVq6HARFVwuWnyMdQ9A1re9Ov+PGyeVzH91Caw@mail.gmail.com>
To: Dean Jackson <dino@apple.com>
Cc: "whatwg@lists.whatwg.org" <whatwg@lists.whatwg.org>
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 <dino@apple.com> wrote:

> I sent this to the public-html@w3.org list:
> http://www.w3.org/mid/B2FFF68C-CD91-4273-8087-EC3058D24322@apple.com
> 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

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:45 UTC