Intent to Ship: WebGL on Android

[Sami Kyostila]

Primary eng (and PM) emails
skyo...@chromium.org

Spec
https://www.khronos.org/registry/webgl/specs/1.0/

Summary
We'd like to enable WebGL support by default on compatible Android devices. More specifically, we'll only do this on devices with GPUs that implement the GL_ARB_robustness OpenGL extension. This extension ensures the GPU provides the needed robustness and security safeguards against malicious WebGL content.

The implementation has been verified against the WebGL 1.0.1 conformance test suite provided by Khronos. WebGL has also been behind a developer early access setting on Android since Chrome M25.

Link to “Intent to Implement” blink-dev discussion
WebGL implementation predates blink-dev.

Is this feature supported on all five Blink platforms (Windows, Mac, Linux, Chrome OS and Android)?
Yes.

OWP launch tracking bug?

http://crbug.com/165997 (Implementation tracking bug: http://crbug.com/112928)

Row on feature dashboard?
Yes.

[Brandon Jones]

I lack the authority to officially give this a LG stamp, but I'd like to say that I support this 100%! I know a lot of developers that have been eagerly awaiting this change.

[Dimitri Glazkov]

LGTM.

On Wed, Jul 31, 2013 at 1:04 PM, Sami Kyostila <skyo...@google.com> wrote:

[Ojan Vafai]

LGTM as well.

Will feature detection work as normal for android builds that do or don't support WebGL?

[Adam Barth]

LGTM

[Kenneth Russell]

+1

[Kenneth Rohde Christiansen]

LGTM!

--
Kenneth Rohde Christiansen
Senior Engineer, WebKit, Qt, EFL
Phone +45 4294 9458 / E-mail kenneth at webkit.org

﹆﹆﹆

[Darin Fisher]

LGTM2

[Sami Kyostila]

Thanks all!

On 31 July 2013 21:44, Ojan Vafai <oj...@chromium.org> wrote:

Will feature detection work as normal for android builds that do or don't support WebGL?

Yes, feature detection is done by trying to create a WebGL context, and that will only succeed on supported devices.

- Sami

[PhistucK]

Will the (deprecated?) "experimental-webgl" context name be supported too, or will only "webgl" be available?

I support the latter, of course.

☆PhistucK

[Brandon Jones]

There is an awful lot of WebGL context that still uses "experimental-webgl", so excluding it would be a very bad idea.

[PhistucK]

On one hand, yes. On the other, most of these demos were not meant really for mobile/small screens anyway and should probably be re-coded or checked for compatibility with the new constraints.

☆PhistucK

[Alex Russell]

I'm inclined to agree, but I'd like to understand this with data. Do we have histograms on this?

[Alexandre Elias]

Chrome for Android supports almost all features of sites designed for desktop even if the experience isn't necessarily ideal, and I don't see why we should have a different policy for WebGL.  The "new constraints" are the same as for any other kind of web platform feature (namely a smaller display and poorer performance).  To provide predictable behavior to web developers, we also strive to support the same set of feature flags.

So I think that when we're ready to remove "experimental-webgl", we should do it at the same time for desktop Chrome and Chrome for Android.

[Darin Fisher]

+1

Please note that this applies to tablets too, which are similar to some laptop hardware ;-)

-Darin

[Paul Lewis]

With respect to 'webg' vs 'experimental-webgl': I have a pull request open for Three.js which has it to request a 'webgl' context should getting 'experimental-webgl' fail. That should at least cover a good bunch of people who may be affected as and when we look to switch.

I am also happy to promote the change as and when we get there, and we should give the WebGL info outlets the heads up, too.

[Sami Kyostila]

Agreed, it doesn't seem like we need to special case mobile platforms w.r.t. context creation. I'll make sure both "webgl" and "experimental-webgl" are supported like on desktop and add a histogram to track what people are using.

- Sami

[Christian Biesinger]

Wouldn't it make more sense to first try "webgl" and only use
experimental-webgl if that fails...?

(that would also help us get better metrics for how many pages use
experimental-webgl vs webgl)

-christian

[PhistucK]

Yes. I am really surprised they only went for experimental-webgl.

A similar mistake was made by rng.io. For some reason, they test for the nonstandard context names first and if they get a context, they bail and assert whether the name is "webgl".

I have a pull request that fixes that. Hopefully, they will accept it and ring 2 would be a little more filled for Chrome. ;)

☆PhistucK

[Sami Kyostila]

Since I've been some getting questions about how common the context
robustness extension is, I thought I'd give an update here. I took a
look a the data on gfxbench.com and 959 out of the 1821 Android
devices on there report the extension. A caveat with this number is
that it includes devices that don't support reset notification which
we also check for (see crbug.com/288731).

The word from the mobile GPU vendors is that the upcoming GPU
generation should have robustness support pretty much across the
board. We're also looking at making WebGL a more prominent part of
Android conformance testing.

- Sami