[whatwg] Challenging canvas.supportsContext
bzbarsky at MIT.EDU
Wed Jun 19 11:29:05 PDT 2013
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
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.
More information about the whatwg