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

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


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

Android Nexus5 Perf
Android Nexus5X WebView Perf

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

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/160f4ad8e40000

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

Telemetry: fix a SF stats collector bug by chiniforooshan@chromium.org
https://chromium.googlesource.com/catapult/+/5f6da8a57db16291c01a894083137c294b3b4e5f
tasks_per_frame_total_all: 42.15 → No values

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

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

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/13199f72e40000

So there are 6 graphs associated with this bug:

- Two tasks_per_frame_total_all graphs: I think regressions in this metric that do not appear in cpu_per_frame_* metrics should be ignored. For example, see  crbug.com/811584 . My CL records Surface Flinger data in the trace file under a new process. So the metric thinks that the number of tasks is increased; which is not correct.

- ChromiumPerf/Android Nexus5X WebView Perf/rendering.mobile/avg_surface_fps: there was no data for this metric since July 19th. My CL fixed it around Sep 25th. It's not the cause of regression, it's causing we get data and see the regression. The regression happened sometime between 7-19 to 9-25.

- ChromiumPerf/Android Nexus5 Perf/rendering.mobile/avg_surface_fps: _ref is regressed at the same time.

- infinite_scroll_element_n_layers_0 and mean_frame_time_renderer_compositor: These two graphs seem to go back to pre-regression levels later. So, whatever caused these is probably fixed. I started a pinpoint job for infinite_scroll_element_n_layers_0 for more investigation.

📍 Found significant differences after each of 2 commits.
https://pinpoint-dot-chromeperf.appspot.com/job/13199f72e40000

Use vpython and remove vendored pymock. by jbudorick@chromium.org
https://chromium.googlesource.com/catapult/+/23c67a511280f6dbc2a2bea849dd7eed5104809e
tasks_per_frame_total_all: 22.89 → No values

Roll src/third_party/catapult e06567b30fdd..64f2ed4bb2f1 (1 commits) by chromium-autoroll@skia-public.iam.gserviceaccount.com
https://chromium.googlesource.com/chromium/src/+/276e662dbc2525240c0d3abe456086f11d04843b
tasks_per_frame_total_all: No values → 23.19

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

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

It's hard to triage the regression in avg_surface_fps between 7-19 to 9-25 since this metric was not being produced during that period. The regression doesn't seem bad: it is changing from oscillating between 61fps and 60fps to always 60fps.

I'll mark this as won't fix (see C#5 for explanations about other regressions associated with this bug).