Intent to Implement and Ship: HTMLCanvasElement supportsContext

[Brandon Jones]

Primary eng/PM emails

baj...@chromium.org

Spec

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

Summary

Adds canvas.supportsContext() to allow developers to query supported context types without needing to create them.

Motivation

Toolkits such as Modernizr want to report canvas capabilities in a non-obtrusive way. Currently they must either create a context, which has a lot of overhead, or they must estimate support by testing for the existence of types, such as "if (window.WebGLRenderingContext) { ... }". This may give false positives if the browser supports WebGL but has it disabled.

Compatibility Risk

Very low. A single new function will be added and existing APIs will not be changed.

Ongoing technical constraints

None.

Will this feature be supported on all five Blink platforms (Windows, Mac, Linux, Chrome OS and Android)?

Yes.

OWP launch tracking bug?

No launch bug, but a feature request bug exists: https://code.google.com/p/chromium/issues/detail?id=251027

Row on feature dashboard?

No. This is a small change which can reasonably be encompassed by "Canvas"

Requesting approval to ship?

Yes.

[Alex Komoroske]

On Tue, Jun 18, 2013 at 10:37 AM, Brandon Jones <baj...@google.com> wrote:

Primary eng/PM emails

baj...@chromium.org

Spec

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

Summary

Adds canvas.supportsContext() to allow developers to query supported context types without needing to create them.

Motivation

Toolkits such as Modernizr want to report canvas capabilities in a non-obtrusive way. Currently they must either create a context, which has a lot of overhead, or they must estimate support by testing for the existence of types, such as "if (window.WebGLRenderingContext) { ... }". This may give false positives if the browser supports WebGL but has it disabled.

Compatibility Risk

Very low. A single new function will be added and existing APIs will not be changed.

This part of the template isn't just the notion of size of the change (we refer to it as "footprint"), but also how likely it is that other browsers will also implement it, whether or not a spec exists, etc. It looks like this is in the WHATWG HTML spec already based on the link above. Do other browsers support it or plan to support it? 

[Erik Arvidsson]

supports and hasFeature APIs are going out of fashion.

On Tue, Jun 18, 2013 at 1:37 PM, Brandon Jones <baj...@google.com> wrote:

Motivation

Toolkits such as Modernizr want to report canvas capabilities in a non-obtrusive way. Currently they must either create a context, which has a lot of overhead, or they must estimate support by testing for the existence of types, such as "if (window.WebGLRenderingContext) { ... }". This may give false positives if the browser supports WebGL but has it disabled.

If the browser disables WebGL we should not expose WebGLRenderingContext.

--
erik

[Brandon Jones]

On Tue, Jun 18, 2013 at 10:58 AM, Alex Komoroske <komo...@chromium.org> wrote:

This part of the template isn't just the notion of size of the change (we refer to it as "footprint"), but also how likely it is that other browsers will also implement it, whether or not a spec exists, etc. It looks like this is in the WHATWG HTML spec already based on the link above. Do other browsers support it or plan to support it? 

It has been already been implemented by WebKit (bug: https://bugs.webkit.org/show_bug.cgi?id=70117). There is a bug filed for Mozilla, but it appears that they may have some reservations (https://bugzilla.mozilla.org/show_bug.cgi?id=884444)

[Kenneth Russell]

WebGL may be dynamically disabled, for example if Chrome determines at
run time that its GPU sub-process is unstable. In this situation the
browser will not spontaneously remove the window.WebGLRenderingContext
property. supportsContext handles this and other use cases.

Additionally, the decision was made some time ago for Chrome that even
if --disable-webgl is passed, the property
window.WebGLRenderingContext is still defined, but getContext('webgl')
will not succeed.

-Ken

[Eugene Girard]

Is there a reason to define window.WebGLRenderingContext when WebGL is disabled? 

Touch events are defined dynamically based on flags/attached devices at run time. See http://crbug.com/152149

[Kenneth Russell]

The rationale is that the browser fundamentally does support WebGL,
but due to the user manually disabling it, Chrome's GPU process
crashing, or other hardware considerations, that it can not be enabled
at the moment. Therefore window.WebGLRenderingContext is exposed, but
context creation will fail. The error message can then be intuited by
the app to be "WebGL is supported in your browser, but couldn't be
enabled." A detail message might be provided to an event handler
registered on the canvas.

Note that WebGL support might be re-enabled, for example if the user
interacts with an infobar. This is why the app should detect it as
being fundamentally available, so it attempts to initialize it again.

-Ken

[PhistucK]

What infobar are you referring to here?

☆PhistucK

[PhistucK]

Adding this just for Modernizr or other feature detection based frameworks/test (html5test?) seems pretty useless (also, they changed their code and now rely on the property instead, but see my next point). If they code it wrong, ask them to fix their code instead of changing the platform.

Exposing properties without having support is wrong. Touch events are exposed in real time, like Eugene stated, so I imagine this should be possible here, too.

Off by default preferences should not affect the web.

I would even argue that WebGL support detection should not be enabled by default in Modernizr, since relatively few actually need it (if you know WebGL, I suspect you know how to easily detect support for it, or how to tick the relevant checkbox in Modernizr for that-graphic-thing-on-which-you-have-worked-for-a-while). But this is unrelated to Blink.

I have not seen any "Want WebGL anyway?" infobar implemented (like Kenneth suggests), so this argument is not really applicable here, as far as I know.

☆PhistucK

[Kenneth Russell]

On Fri, Jun 21, 2013 at 2:17 PM, PhistucK <phis...@gmail.com> wrote:
> Adding this just for Modernizr or other feature detection based
> frameworks/test (html5test?) seems pretty useless (also, they changed their
> code and now rely on the property instead, but see my next point). If they
> code it wrong, ask them to fix their code instead of changing the platform.
>
> Exposing properties without having support is wrong. Touch events are
> exposed in real time, like Eugene stated, so I imagine this should be
> possible here, too.
> Off by default preferences should not affect the web.
>
> I would even argue that WebGL support detection should not be enabled by
> default in Modernizr, since relatively few actually need it (if you know
> WebGL, I suspect you know how to easily detect support for it, or how to
> tick the relevant checkbox in Modernizr for
> that-graphic-thing-on-which-you-have-worked-for-a-while). But this is
> unrelated to Blink.
>
> I have not seen any "Want WebGL anyway?" infobar implemented (like Kenneth
> suggests), so this argument is not really applicable here, as far as I know.

Chrome pops up an infobar "Rats, WebGL hit a snag!" on pages running
WebGL if the underlying OpenGL context is lost. Reasons this might
happen:

- Chrome's GPU sub-process hangs (perhaps because of a very
long-running draw call) and its watchdog terminates and restarts the
process.

- A watchdog in the graphics driver is triggered (via the
GL_ARB_robustness or GL_EXT_robustness OpenGL and OpenGL ES
extensions) and the OpenGL context is lost (again, possibly because of
a long-running draw call).

There's an ongoing discussion on whatwg about this feature where the
debate should probably be continued.

-Ken

[PhistucK]

Sounds like an infobar that shows up after creating a context and actually using it, or am I mistaken?

☆PhistucK

[Kenneth Russell]

Correct. The infobar only shows up if something has gone seriously
wrong while WebGL content was running. It's intended only to address
denial of service concerns and should not show up in normal usage.
(The Chrome team is continuing to investigate why it pops up more than
desired.)

[Dimitri Glazkov]

On Mon, Jun 24, 2013 at 4:43 AM, Kenneth Russell <k...@chromium.org> wrote:
> There's an ongoing discussion on whatwg about this feature where the
> debate should probably be continued.

Here's a link to the discussion:
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2013-June/thread.html#39777

I agree about continuing this discussion on whatwg mailing list. Once
the consensus emerges, we can get back to discussion this intent.

:DG<

[Eric Seidel]

It sounds like this proposal has been aborted?

I'm also not in favor of adding more supports* apis. The ones we have
on the web already are broken and unusable, with
DocumentImplementation.hasFeature being the worst offender. :)