- From: Gregg Tavares <gman@google.com>
- Date: Thu, 20 Jun 2013 15:50:53 -0700
- To: Kenneth Russell <kbr@google.com>
- Cc: whatwg <whatwg@lists.whatwg.org>, Brandon Benvie <bbenvie@mozilla.com>, James Robinson <jamesr@google.com>
On Wed, Jun 19, 2013 at 3:24 PM, Kenneth Russell <kbr@google.com> wrote: > On Wed, Jun 19, 2013 at 3:06 PM, James Robinson <jamesr@google.com> wrote: > > On Wed, Jun 19, 2013 at 3:04 PM, Kenneth Russell <kbr@google.com> wrote: > >> > >> On Wed, Jun 19, 2013 at 2:20 PM, Brandon Benvie <bbenvie@mozilla.com> > >> wrote: > >> > On 6/19/2013 2:05 PM, James Robinson wrote: > >> >> > >> >> What would a page using Modernizr (or other library) to feature > detect > >> >> WebGL do if the supportsContext('webgl') call succeeds but the later > >> >> getContext('webgl') call fails? > >> > > >> > > >> > I don't have an example, I was just explaining how Mozernizr is often > >> > used. > >> > > >> > > >> >> I'm also failing to see the utility of the supportsContext() call. > >> >> It's > >> >> impossible for a browser to promise that supportsContext('webgl') > >> >> implies > >> >> that getContext('webgl') will succeed without doing all of the > >> >> expensive > >> >> work, so any correctly authored page will have to handle a > >> >> getContext('webgl') failure anyway. > >> > > >> > > >> > Given this, it would seem supportsContext is completely useless. The > >> > whole > >> > purpose of a feature detection check is to detect if a feature > actually > >> > works or not. Accuracy is more important than cost. > >> > >> supportsContext() can give a much more accurate answer than > >> !!window.WebGLRenderingContext. I can only speak for Chromium, but in > >> that browser, it can take into account factors such as whether the GPU > >> sub-process was able to start, whether WebGL is blacklisted on the > >> current card, whether WebGL is disabled on the current domain due to > >> previous GPU resets, and whether WebGL initialization succeeded on any > >> other page. All of these checks can be done without the heavyweight > >> operation of actually creating an OpenGL context. > > > > > > That's true, but the answer still doesn't promise anything about what > > getContext() will do. It may still return null and code will have to > check > > for that. What's the use case for calling supportsContext() without > calling > > getContext()? > > Any application which has a complex set of fallback paths. For example, > > - Preference 1: supportsContext('webgl', { softwareRendered: true }) > - Preference 2: supportsContext('2d', { gpuAccelerated: true }) > - Preference 3: supportsContext('webgl', { softwareRendered: false }) > - Fallback: 2D canvas > How would those checks work? In Chrome for example there are opaque heuristics for gpu accelerated 2d. So now you'd need supportsContext('2d', {gpuAccelerated: true, width: someWidth, height: someHeight, intendedUse: "line drawing" }); > > I agree that ideally, if supportsContext returns true then -- without > any other state changes that might affect supportsContext's result -- > getContext should return a valid rendering context. It's simply > impossible to guarantee this correspondence 100% of the time, but if > supportsContext's spec were tightened somehow, and conformance tests > were added which asserted consistent results between supportsContext > and getContext, would that address your concern? > > -Ken >
Received on Thursday, 20 June 2013 22:51:18 UTC