Re: [whatwg] Challenging canvas.supportsContext

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

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 Wednesday, 19 June 2013 22:24:51 UTC