- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Wed, 19 Jun 2013 14:29:05 -0400
- To: whatwg@lists.whatwg.org
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
Received on Wednesday, 19 June 2013 18:29:31 UTC