[whatwg] Challenging canvas.supportsContext

[Kenneth Russell]

Looking back at the previous discussion:

  http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-September/037229.html
(and succeeding emails)
  http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-October/037693.html

Accurate feature detection in libraries like Modernizr was mentioned
as a key use case:

  http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-September/037249.html

Additionally, though, application developers wanted to be able to ask
questions like "is software rendering supported for WebGL":

  http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-September/037232.html

I think this second use case is valid. One could imagine a graphing or
charting library which would use low-power, software-rendered WebGL if
available, but otherwise would fall back to using
CanvasRenderingContext2D.

I'd like to see supportsContext remain in the spec.

-Ken



On Wed, Jun 19, 2013 at 12:34 PM, Tab Atkins Jr. <jackalmage at gmail.com> wrote:
> On Wed, Jun 19, 2013 at 11:29 AM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
>> On 6/19/13 2:17 PM, Benoit Jacob wrote:
>>> The closest thing that I could find being discussed, was use cases by JS
>>> frameworks or libraries that already expose similar feature-detection
>>> APIs.
>>> However, that only shifts the question to: what is the reason for them to
>>> expose such APIs?
>>
>>
>> I _think_ the issue is poorly-designed detection APIs that do the detection
>> even if the consumer of the framework/library doesn't care about that
>> particular feature.
>>
>> That means that right now those frameworks are doing a getContext() call but
>> then no one cares that they did.
>>
>>
>>> There is also the argument that supportsContext can be much cheaper than a
>>> getContext, given that it only has to guarantee that getContext must fail
>>> if supportsContext returned false. But this argument is overlooking that
>>> in
>>> the typical failure case, which is failure due to system/driver
>>> blacklisting, getContext returns just as fast as supportsContext
>>
>> I think the argument here is that the common case for getContext is in fact
>> more and more the success case.  So the framework/library is wasting time
>> successfully creating a context that no one actually cares about.
>>
>> If the above is correct, I agree with Benoit: the right fix is to fix the
>> libraries to do the getContext() lazily when someone actually asks whether
>> WebGL is enabled.
>>
>> If I'm wrong, then I'd like to understand what problem we _are_ trying to
>> solve.  That is, what the cases are that want to check that they can create
>> a context but not actually create one.
>
> This is missing the point.  You don't want to wait until it's actually
> time to create the context.  Unless you torture your code flow, by the
> time you're creating a context you should already know that the
> context is supported.  The knowledge of which context to use is most
> useful well before that, when you're first entering the app.
>
> Plus, it doesn't matter how late you do the detection - if you do a
> straight *detection* at all rather than an initialization (that is, if
> you throw away the context you've just created for testing), you'll
> still incur the start-up costs of spinning up a context.  Doing that
> early or late doesn't matter too much - it's bad either way.
>
> Like @supports, the supportsContext() method can be easy and reliable
> with a very simple definition for "supports" - it returns true if
> calling getContext() with the same arguments would return a context
> rather than erroring, and false otherwise.  No capacity for lying
> there without breaking sites.
>
> ~TJ