There are some inherent limitations if we still want to base this on swaps.

* in webview, android code, not chromium code, calls eglSwapBuffers. the SwapBuffers call in webview only flushes the command buffer
* swap buffer may never happen for a frame, and android doesn't provide singals like "commit failed" that tells us the swap won't happen, android just doesn't call back to webview

Interesting. So I guess it's actually impossible for us to measure input to paint latency then?

I can't think of a solid way like chrome is able to do. :/

you can think of webview as a cc::Layer in android view compositor, and a layer doesn't really need to see or know everything that's going on in the compositor..

This is hard, but we should think about it at some point.

We should align our metrics with areas of responsibility.  The WebView itself is only part of what goes into end-to-end scroll/draw and isn't made aware of the rest.  I think for automated alert style tests, what would make sense is for the test embedder app to report metrics instead of the WebView.

For field metrics, getting them at all in WebView is a work-in-progress (http://crbug.com/487268 ).  Once that's working at all, we should start getting the lower-level metrics -- but we should probably give up on the idea of collecting stuff like end-to-end latency from the field.  Personally, I think automated WebView coverage + Chrome field coverage are decent enough proxies that I'm not particularly afraid a regression would slip through, anyway.

> I think for automated alert style tests, what would make sense is for the test embedder app to report metrics instead of the WebView.

Android render thread (where eglSwapBuffers is called by android) is completely hidden from apps as well. This really has to be instrumentation added by android. There are already systrace events for eglSwapBuffers, so may be possible to just tap into that somewhow?

The biggest thing we're missing here is telemetry coverage of scroll latency.

Do you think we should try plumbing up an embedder that would report information to telemetry, or something like that? That sounds like it would likely take some work from the telemetry infra folks.

I'm not so confident that automated WebView coverage + Chrome field coverage are good enough. We've seen lots of regressions that are Android device specific, and I suspect that WebView is more different from Chrome than some of the devices that behave differently are from each other.

Automated WebView coverage is definitely the right place to focus first though.

Quinten, can someone from infra team help here to make some progress.

I'm not sure myself, so I'll ask people who know better than me:

Ned or Annie, do you know what scrolling metrics for WebView might involve, or if this fits into any existing plans?

We already run a bunch of smoothness test on Webview browser (https://build.chromium.org/p/chromium.perf/builders/Android%20Nexus5X%20WebView%20Perf/builds/728)

I would defer questions about development of webview scrolling metrics to vmiura@