- From: Ashley Gullen <ashley@scirra.com>
- Date: Mon, 10 Sep 2012 20:35:30 +0100
- 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 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:36:08 UTC