W3C home > Mailing lists > Public > whatwg@whatwg.org > June 2013

Re: [whatwg] Challenging canvas.supportsContext

From: Kenneth Russell <kbr@google.com>
Date: Wed, 19 Jun 2013 15:56:24 -0700
Message-ID: <CAMYvS2cyBrot11bYmYHHKLkGRbgXkS9chSCKHUnvEyod2eJGhA@mail.gmail.com>
To: James Robinson <jamesr@google.com>
Cc: whatwg <whatwg@lists.whatwg.org>, Brandon Benvie <bbenvie@mozilla.com>
On Wed, Jun 19, 2013 at 3:39 PM, James Robinson <jamesr@google.com> wrote:
>
>
>
> 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:
>> >>
>> >> 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'm assuming you have (1) and (3) flipped here and both supportsContext()
> and getContext() support additional attributes to dictate whether a
> software-provided context can be supplied.  In that case, in order to write
> correct code I'd still have to attempt to fetch the contexts before using
> them, i.e.:
>
> var ctx = canvas.getContext('webgl', { 'allowSoftware': false});
> if (ctx) {
>   doPreference1(ctx);
>   return;
> }
> ctx = canvas.getContext('2d', {'allowSoftware': false});
> if (ctx) {
>   doPreference2(ctx);
> // etc
>
> how could I simplify this code using supportsContext() ?
>
>
>>
>> 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 seems overwhelmingly likely that one of the state changes that might
> affect the result will be attempting to instantiate a real context.

In my experience, in Chromium, creation of the underlying OpenGL
context for a WebGLRenderingContext almost never fails in isolation.
Instead, more general failures happen such as the GPU process failing
to boot, or creation of all OpenGL contexts (including the
compositor's) failing. These failures would be detected before the app
calls supportsContext('webgl'). For this reason I believe
supportsContext's answer can be highly accurate in almost every
situation.

>>
>> 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?
>
>
> I don't see how supportsContext() could be as accurate as getContext()
> without doing all of the work getContext() does.  If it's not 100% accurate,
> when is it useful?

This is a specious question. My point is that the answer can be
accurate enough to be useful, and I'm personally willing to sign up to
make the implementation follow a stricter spec.

-Ken


> - James
>
>
>>
>>
>> -Ken
>
>
Received on Wednesday, 19 June 2013 22:56:49 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:22 UTC