884444 - Add support for canvas supportsContext

Status: RESOLVED WONTFIX

(Core :: DOM: Core & HTML, defect)

Description

[(no longer active)]

http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-canvas-supportscontext

This seems useful and very easy.  Blink is also implementing it.

Comment 1

[Benoit Jacob [:bjacob] (mostly away)]

What does this offer that getContext() doesn't?

If one wants truly reliable testing of whether one can actually get a context of a given id, given driver bugs, limited resources (especially on mobile devices which may not allow having many GL context's...), and blacklisting, then there is no way to implement supportsContext in a way that'd be faster than getContext().

If, on the other hand, one only wants to know if the browser is in principle meant to offer this context id, then it's enough to test for the existence of the corresponding JS interface.

The spec doesn't seem to imply that supportsContext() should return true if and only if getContext() would succeed. The only thing it says is:

> The supportsContext(contextId, arguments...) method of the canvas element, when invoked, must return false if calling getContext() on the same object and with the same arguments would definitely return null at this time, and true otherwise.

If I understand correctly, the only thing that this guarantees is that if supportsContext returns false than getContext must fail. If that is correct, then a compliant implementation of supportsContext is to return whether the corresponding JS interface exists.

The more productive thing to do, though, is to kill down this idea in the working group.

Comment 2

[Rik Cabanier]

(In reply to Benoit Jacob [:bjacob] from comment #1)
> What does this offer that getContext() doesn't?
> 
> If one wants truly reliable testing of whether one can actually get a
> context of a given id, given driver bugs, limited resources (especially on
> mobile devices which may not allow having many GL context's...), and
> blacklisting, then there is no way to implement supportsContext in a way
> that'd be faster than getContext().

This feature is here to do a quick check so you can reasonably assert that you can create a WebGL context without resorting to actually creating one.
Tools such as modernizer, create a 3d context as part of their feature sniffing which is expensive.

Comment 3

[Benoit Jacob [:bjacob] (mostly away)]

So this is an intermediate reliability/speed compromise, half-way between the reliable-and-slow getContext and the unreliable-and-fast JS interface check? I'm not convinced that this is useful enough to exist, especially as the primary usage pattern here will be

  if (canvas.supportsContext("webgl")) {
    result = canvas.getContext("webgl");
  } else {
    result = canvas.getContext("2d");
  }

and that is going to do exactly the same thing as what is currently done (and working everywhere):

  result = null;
  try {
    result = canvas.getContext("webgl");
  } catch(e) {}
  if (!result) {
    result = canvas.getContext("2d");
  }

...in fact, the only tangible difference is that the supportsContext version is going to be a little bit /slower/ as it performs part of the same work as one is going to do anyways in getContext.

Comment 4

[Benoit Jacob [:bjacob] (mostly away)]

...oh, and assuming that supportsContext is going to be just, as suggested in comment 2, a "quick check", that means that even if it returns true, so one will still have to verify getContext()'s success, so the supportsContext-using context creation code is going to be like

  result = null;
  if (canvas.supportsContext("webgl")) {
    try {
      result = canvas.getContext("webgl");
    } catch(e) {}
  }
  if (!result) {
    result = canvas.getContext("2d");
  }

Comment 5

[Benoit Jacob [:bjacob] (mostly away)]

SVN blame gives:

r7482 | ianh | 2012-10-22 19:36:56 -0400 (Mon, 22 Oct 2012) | 2 lines

[giow] (0) Add supportsContext()
Affected topics: Canvas, DOM APIs

...and a google search points to this thread:

http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-October/037693.html

Comment 6

[(no longer active)]

(In reply to comment #5)
> SVN blame gives:
> 
> r7482 | ianh | 2012-10-22 19:36:56 -0400 (Mon, 22 Oct 2012) | 2 lines
> 
> [giow] (0) Add supportsContext()
> Affected topics: Canvas, DOM APIs
> 
> ...and a google search points to this thread:
> 
> http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-October/037693.html

> To give a real world example, the popular tool Modernizr tests for the 
> availability of WebGL by attempting to create a WebGL context. This can 
> happen even on pages that have no intention of using WebGL - an author 
> has just inserted Modernizr into their page and is using it to test for 
> another feature. As I said, creating a context is not a free operation. 
> In fact, on shipping Safari (Mountain Lion) this causes us to switch to 
> a more powerful GPU on systems that have two graphics processors.

Comment 7

[Benoit Jacob [:bjacob] (mostly away)]

I suspect that this feature is only useful from the perspective of _frameworks_ such as Modernizr, only as a side-effect of the particular choice of abstract problems that they try to solve, and is not actually useful to _applications_. The reason why I suspect that, is that applications don't just want to test whether WebGL is available --- rather, they want to _use_ WebGL if available and use something else otherwise. In that case, since they want to do a getContext anyway, there is no benefit for them in a separate call to try to predict what getContext's chances of success would be.

Comment 8

[Benoit Jacob [:bjacob] (mostly away)]

The corresponding Chromium bug is https://code.google.com/p/chromium/issues/detail?id=251027

I asked what their reasons were to want to implement this. I'll take the issue to WhatWG later, based on the feedback I get here and on the Chromium bug.

Comment 9

[Benoit Jacob [:bjacob] (mostly away)]

Started a thread on WhatWG:
  http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2013-June/039777.html

Comment 10

[bjornson]

This was removed from the spec.

Removed from WebKit: https://bugs.webkit.org/show_bug.cgi?id=161692.
Wontfix for Chromium: https://bugs.chromium.org/p/chromium/issues/detail?id=251027.