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

Re: [whatwg] [canvas] Proposal for supportsContext

From: Dean Jackson <dino@apple.com>
Date: Mon, 10 Sep 2012 12:39:24 -0700
Message-id: <094D9963-D673-45A7-B874-54FB0B6C5C60@apple.com>
To: Ashley Gullen <ashley@scirra.com>
Cc: "whatwg@lists.whatwg.org" <whatwg@lists.whatwg.org>

On Sep 10, 2012, at 12:35 PM, Ashley Gullen <ashley@scirra.com> wrote:

> 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)

Yes, it could. But we don't control Modernizr or any other scripts people might use. I'd rather provide something at the browser-level to protect from bad practice than expect every page to behave nicely.

> 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 })

Yes, that was another part of the eventual plan, although I didn't want to define that yet.

Dean

> 
> Despite the hardness to define it, I do feel there is a practical need for this.
> 
> Ashley Gullen
> Scirra.com
> 
> 
> 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:40:10 UTC

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