Re: [whatwg] Challenging canvas.supportsContext

On Tue, Jun 25, 2013 at 6:48 PM, Simon Pieters <simonp@opera.com> wrote:

> On Wed, 26 Jun 2013 01:39:01 +0200, Glenn Maynard <glenn@zewt.org> wrote:
>
>  This is done if the feature is being disabled completely at page load
>> time,
>> with no chance of it coming back: you simply don't put the interface into
>> the environment.  WebGL is different, since it might go away after the
>> page
>> is already loaded (eg. the GPU blacklist is updated); going in and trying
>> to remove the interface after the page is loaded would be weird.  It might
>> also become available after previously being unavailable (eg. video
>> drivers
>> are updated), in which case you'd have to go in and insert the interface.
>>
>
> That's a good point. But the above also means that supportsContext is not
> useful in such cases since the environment can have changed between the
> time supportsContext is called and the time you want to create a context.


That's inherent however it's done, since it's usually impossible to
guarantee this; too much is out of the control of the browser.  Even if you
call getContext("gl") twice in a row, one might succeed and the other fail.

That doesn't mean it's not useful, but it does mean it's harder to use
correctly.  For example, if Google Maps wants to show an "enable WebGL
maps" button only if WebGL is available, supportsContext() can be useful to
tell whether to show the button.  That's useful even if it's not perfect:
if that hides the button correctly for 99% of users, and gives a button
that shows "sorry, WebGL didn't actually work!" for the remaining 1%, then
that's an improvement over a useless button for 100% of users.  If they
want to show the button in the uncommon case of WebGL becoming available
later on, they'd also want to recheck support periodically (eg. on focus or
something).

This is all far from perfect--web APIs try hard to avoid this sort of
nondeterministic behavior.  I don't know enough about the costs of actually
creating a context to know whether it's worth it.  But, I disagree that
being imperfect means it's not useful at all.

(FWIW, if I remember correctly, the basic idea of supportsContext was to
discourage badly-written libraries, used on pages that don't even care
about WebGL, from always creating a context just to fill in a feature
support table, causing lots of pages to create and immediately discard
rendering contexts all the time.)

On Tue, Jun 25, 2013 at 6:46 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> I don't think any of the current proposals supports that use case. For
> that to be really supported we'd need some sort of event that is fired
> whenever support for WebGL is dynamically added or removed. Pages
> having to continuously poll .supportsContext() is not a real solution.
>
> Has any browser actually expressed interest in supporting that use case?
>

I recall the driver blacklist issue coming up before, where WebGL is
available when the page is loaded, but is disabled later due to a
background update to the blacklist.  Sorry, it was years ago and I don't
recall who that discussion was with.
https://www.khronos.org/webgl/public-mailing-list/archives/1104/msg00136.htmlis
the closest reference to the discussion I can find.

-- 
Glenn Maynard

Received on Wednesday, 26 June 2013 00:38:39 UTC