IIRC we don't really support the Android Emulator in WebView, but I might be wrong.
Torne, do you have any thoughts on this?

Setting this as P3 since the WebView version is 55.

I don't know what the swiftshader-based GPU emulation on the emulator is capable of, but for full graphics functionality in WebView we require either:

1) that the GL implementation supports the robustness extension
2) or that the reset strategy is nonzero

These are both displayed in chrome://gpu but you didn't screenshot those parts :)
If the emulator in this configuration still doesn't have one or both of those things, then WebView's graphics support is still going to be limited, and it may affect video (as well as WebGL).

Also, in general we don't recommend testing WebView functionality on the emulator at all: the emulator doesn't have an updatable version of WebView and so you're using an outdated version that doesn't reflect what the majority of users on real devices actually have, plus the graphics incompatibilities mean that the functionality and performance is not the same. We have a minimal set of workarounds to make sure WebView can function at all on the emulator, but that's about all we do.

Hi:

Thanks for the reply. I'm adding some additional screenshots on GL_EXTENSIONS and (reset notification strategy?)

What make me confused is Chrome works fine but webview didnt get video rendered. Is this an expected behavior?

Thanks.

Deleted: Screenshot_1497593625.png 287 KB

	Screenshot_1497593625.png 287 KB View Download

Deleted: Screenshot_1497593629.png 246 KB

	Screenshot_1497593629.png 246 KB View Download

Deleted: Screenshot_1497593635.png 174 KB

	Screenshot_1497593635.png 174 KB View Download

Deleted: Screenshot_1497593638.png 225 KB

	Screenshot_1497593638.png 225 KB View Download

Deleted: Screenshot_1497593664.png 221 KB

	Screenshot_1497593664.png 221 KB View Download

Torne, I'm gonna assign this to you since you know what to look for in chrome://gpu, feel free to re/un-assign :)

There's no robustness extension and the reset strategy is 0, so yes, this is unfortunately working as intended - the emulator with swiftshader is still not good enough.

Chrome doesn't have this restriction because it has a separate graphics context for rendering and so doesn't need the guarantees of robustness. WebView shares its graphics context with your app.

Use real devices for webview testing.

Actually, this is probably the emulator check: https://cs.chromium.org/chromium/src/android_webview/java/src/org/chromium/android_webview/AwContents.java?rcl=219666dbe44bdadde0dc0edb2c03c5647ba1f1bb&l=121

On regular devices (with in-process gpu), only webgl depends on robustness extension. other things like video shouldn't depend on robustness.

Ah, sorry.

I guess the swiftshader mode in the emulator might need yet more special case handling here then, if we expect it to work? The general level of support looks like it might be enough, even if we still can't enable webgl for lack of robustness..

Do we think it's worth doing that?

I've _heard_ swiftshader is good enough for everything (except webgl I guess, due to robustness extension). So in theory, I'd like to just remove that line altogether.

But emulator folks requested that line being added, and has not requested that line being modified or removed. I don't even know what emulators and what builds of those emulators are out there, so no idea how to test this. Probably should ask the emulator people..

Note that as of Chrome M59 we've fully integrated SwiftShader into Chrome on Windows and Linux desktop for seamless WebGL fallback support. We're also running ClusterFuzz tests now, as well as ASan, MSan, TSan, and UBSan builds in various places. So we have good confidence in its stability.

That said, we're still adhering to garbage-in-garbage-out, meaning that if you pass in a bad pointer or insufficient memory has been allocated to perform a certain operation, things may crash (e.g.  crbug.com/734245 ). However, it's the command buffer's responsibility to validate these things. I'm not sure if WebView uses the command buffer? If it does then it should be quite safe to use SwiftShader despite the current lack of GL_EXT_robustness extension support.

SwiftShader actually already implements all of the entry functions of the GL_EXT_robustness extension (which I was a co-author of). The one thing that keeps us from claiming full support for this extension is that we don't yet guarantee not to crash the application. It could probably be done by using a signal handler though, and then putting the context in a lost state just like with a physical device.

So let me know if that's something you'd like me to look into.

for integrating into chrome:

how does that integration work on desktop chrome? just have webgl run in swiftshader but still have compositing in GL, so need a upload in between? or compositing has to be in software as well? asking because chrome on android doesn't have a software compositor

also how's the general performance? I imagine puny mobile processors probably can't handle workload meant for the gpu very well, certainly not as well as desktop

for implementing it for emulator, I guess that's a question for emulator people how much they care about having webgl in webview working in emulator

Using SwiftShader for WebGL on desktop Chrome currently disables all uses of the GPU. We're hoping to change that, especially for WebGL 2 where lots of blacklisted GPUs are still perfectly capable of doing compositing and perhaps rasterization. Anyway, I merely mentioned this integration to highlight SwiftShader's stability. We're passing the full WebGL 1.0.4 conformance test suite now too.

On the Android Emulator, SwiftShader can take the role of the system's graphics driver. Chrome isn't even aware that it's not running on a physical GPU. So the lack of specialized CPU compositing isn't a problem. Chrome desktop can also run on SwiftShader this way, but it currently requires a command line flag or substituting with ANGLE's libraries. Either way there's several options to get everything running.

Performance is quite good. On a powerful CPU but a low-end integrated GPU we're getting as close as 50% of performance, and we're not even using AVX2 (or the recent AVX-512) extensions. ARM support is in development for Android Things, and I'm curious to see how that will perform.

Back on topic, I don't see any major reason why WebView shouldn't be fully featured when running on SwiftShader. Robustness against program termination is also the command buffer's responsibility, and we're plugging the holes as we speak. If you're strict about requiring EXT_robustness to enable WebGL support and there's enough demand for this, then we can look into implementing that.

Ok, so swiftshader isn't really ready for direct integration in to chrome android yet.

Again, I'd defer the emulator part of the question to emulator people.

Fwiw, webview requires robustness for webgl because it always runs gpu in-process, so it's not possible to just kill the gpu process if there's a runaway shader or something. Chrome runs gpu out of process for devices with at least 1G of ram (dunno the exact cutoff), and if that's the case, then chrome doesn't require robustness extension to enable webgl.