[whatwg] Challenging canvas.supportsContext

[Boris Zbarsky]

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.

-Boris