- From: Dean Jackson <dino@apple.com>
- Date: Mon, 10 Sep 2012 11:14:30 -0700
- To: "whatwg@lists.whatwg.org" <whatwg@lists.whatwg.org>
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 18:15:12 UTC