- From: Kenneth Russell <kbr@google.com>
- Date: Wed, 19 Jun 2013 12:43:36 -0700
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- Cc: WHATWG <whatwg@lists.whatwg.org>, Boris Zbarsky <bzbarsky@mit.edu>
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@gmail.com> wrote: > On Wed, Jun 19, 2013 at 11:29 AM, Boris Zbarsky <bzbarsky@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
Received on Wednesday, 19 June 2013 19:44:02 UTC