Re: [whatwg] Challenging canvas.supportsContext

Ping --- I thought that there was sufficient agreement in this thread,
around the fact that supportsContext, as currently spec'd and currently
implementable, is a feature without a valid use case, that removing it from
the spec is the right thing to do at this point.

Benoit


2013/7/18 Benoit Jacob <jacob.benoit.1@gmail.com>

> The thread seems to have settled down.
>
> I still believe that supportsContext, in its current form, should be
> removed from the HTML spec, because as currently spec'd it could be
> implemented as just returning whether WebGLRenderingContext is defined. I
> also still believe that it will be exceedingly hard to spec supportsContext
> in a way that makes it useful as opposed to just calling getContext.
>
> Emails in this thread have conveyed the idea that it is already useful to
> return whether WebGL is at least not blacklisted, regardless of whether
> actual context creation would succeed. That, however, is impossible to
> specify, and depends too much on details of how some current browsers and
> platforms work:
>  - driver blacklists will hopefully be a thing of the past, eventually.
>  - on low-end mobile devices, the main cause of WebGL context creation
> failure is not blacklists, but plain OpenGL context creation failures, or
> non-conformant OpenGL behavior, or OOM'ing right after context creation.
> For these reasons, justifying supportsContext by driver blacklisting seems
> like encoding short-term contingencies into the HTML spec, which we
> shouldn't do. Besides, even if we wanted to do that, there would remain the
> problem that that's impossible to spec in a precise and testable way.
>
> For these reasons, I still think that supportsContext should be removed
> from the spec.
>
> Benoit
>
>
>
> 2013/6/19 Benoit Jacob <jacob.benoit.1@gmail.com>
>
>> Dear list,
>>
>> I'd like to question the usefulness of canvas.supportsContext. I tried to
>> think of an actual application use case for it, and couldn't find one. It
>> also doesn't seem like any valid application use case was given on this
>> list when this topic was discussed around September 2012.
>>
>> 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? In the end, I claim that the only thing that we should
>> recognize as a reason to add a feature to the HTML spec, is *application*use cases.
>>
>> So let's look at the naive application usage pattern for supportsContext:
>>
>>   if (canvas.supportsContext("webgl")) {
>>     context = canvas.getContext("webgl");
>>   }
>>
>> The problem is that the same can be achieved with just the getContext
>> call, and checking whether it succeeded.
>>
>> In other words, I'm saying that no matter what JS libraries/frameworks
>> may offer for feature detection, in the end, applications don't want to
>> just *detect* features --- applications want to *use* features. So
>> they'll just pair supportsContext calls with getContext calls, making the
>> supportsContext calls useless.
>>
>> 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 --- as
>> they both just check the blacklist and return. Outside of exceptional cases
>> (out of memory...), the slow path in getContext is the *success* case,
>> and again, in that case a real application would want to actually *use*that context.
>>
>> Keep in mind that supportsContext can't guarantee that if it returns
>> true, then a subsequent getContext will succeed. The spec doesn't require
>> it to, either. So if the existence of supportsContext misleads application
>> developers into no longer checking for getContext failures, then we'll just
>> have rendered canvas-using applications a little bit more fragile. Another
>> problem with supportsContext is that it's untestable, at least when it
>> returns true; it is spec-compliant to just implement it as returning
>> whether the JS interface for the required canvas context exists, which is
>> quite useless. Given such deep problems, I think that the usefulness bar
>> for accepting supportsContext into the spec should be quite high.
>>
>> So, is there an application use case that actually benefits from
>> supportsContext?
>>
>> Cheers,
>> Benoit
>>
>>
>

Received on Wednesday, 31 July 2013 15:26:36 UTC