[whatwg] Challenging canvas.supportsContext

[Gregg Tavares]

On Wed, Jun 19, 2013 at 3:24 PM, Kenneth Russell <kbr at google.com> wrote:

> On Wed, Jun 19, 2013 at 3:06 PM, James Robinson <jamesr at google.com> wrote:
> > On Wed, Jun 19, 2013 at 3:04 PM, Kenneth Russell <kbr at google.com> wrote:
> >>
> >> On Wed, Jun 19, 2013 at 2:20 PM, Brandon Benvie <bbenvie at 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
>