[whatwg] Challenging canvas.supportsContext

[Tab Atkins Jr.]

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