All graphs for this bug:
  https://chromeperf.appspot.com/group_report?bug_id=883356

(For debugging:) Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?sid=9b3d39263738e91f0f1bfae81f585c6a1d5316627116ed9ea2f932b70cd1d3e2


Bot(s) for this bug's original alert(s):

Android Nexus5X WebView Perf

rendering.mobile - Benchmark documentation link:
  https://bit.ly/rendering-benchmarks

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/11015440e40000

📍 Found a significant difference after 1 commit.
https://pinpoint-dot-chromeperf.appspot.com/job/11015440e40000

aw: ReturnedResourceAvailable by boliu@chromium.org
https://chromium.googlesource.com/chromium/src/+/0d8d0e26871adce7024452945a9aec30ac18989c
0.279 → 1.172 (+0.8933)

Understanding performance regressions:
  http://g.co/ChromePerformanceRegressions

Benchmark documentation link:
  https://bit.ly/rendering-benchmarks

Well, if you look at the graph, something caused the asteroid game to simply break (and stop updating) in "Chromium Commit Position range: 589784 - 589785". Then apparently my CL unbroke it. I wasn't expecting that for my CL to do anything like that though, and it might be masking something else, so I guess worth investigating. But overall, this is a false alarm.

And I'm going to complain about perf tests every time. The bug used to have the exact command the bot used to run the test. That seemed to have disappeared, and http://g.co/ChromePerformanceRegressions has very few details. I still have yet to figure out the magic command arguments for my local run to give me a trace.

Telemetry deletes all the logcat on the device after running the test so I can't look at it afterwards, but I don't think it's saved anywhere. And I have yet to find the where the test page lives so I can try it outside of telemetry.

Too much magic, not enough documentation.

Things are indeed broken. This CL breaks webview rendering of that website:
https://chromium.googlesource.com/chromium/src/+/0dd63a3394566a94619974f91ce14f8d7680512c

Open https://testdrive-archive.azurewebsites.net/Performance/AsteroidBelt/Default.html in a webview. Right now it's limping at 15fps due to my CL that returns resources after a 2 frame delay: https://chromium-review.googlesource.com/1214700

But if you revert my CL, then the animation just stops. And reverting your CL brings it back up to 60fps. Doesn't affect chrome at all though.

ericrk: are you aware of this already? Should I dig into this more?

I'm on this - a revert for the CL in question was already in the CQ due to other issues: https://chromium-review.googlesource.com/c/chromium/src/+/1224456

Will investigate more before re-landing anything.

 Issue 883822  has been merged into this issue.

Reverted so no need to block

 Issue 883821  has been merged into this issue.

Issue 883801 has been merged into this issue.

I ended up taking a different approach to backpressure, so not re-landing this. Closing.

 Issue 886817  has been merged into this issue.

 Issue 887476  has been merged into this issue.

 Issue 887282  has been merged into this issue.

 Issue 887377  has been merged into this issue.

 Issue 886822  has been merged into this issue.

Able to verify on Samsung S8/R16NW having 71.0.3561.0, the revert CL as per #6,the animation just stops and brings it back up to 60fps.Since #12 mentions no plan to reland this CL, So marling verified. Please reopen if CL needs to be relanded. Thanks.