[whatwg] Challenging canvas.supportsContext

[Benoit Jacob]

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 at 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
>
>