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

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


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

android-nexus5

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/15a572f1440000

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/16b05db9440000

The culprit CL: https://crrev.com/c/957046, it switches traces to use "Compositor thread" instead of "Compositor" for a thread name. 

This breaks all timeline-based metrics because the script expects the name to be "Compositor": https://cs.chromium.org/chromium/src/tools/perf/metrics/timeline.py?rcl=ac01799a7a69e348f68e9c12c886ee7afc126997&l=24

tdresser@: what would be better: to change the thread name back or to adjust a name that benchmarks use?

I'm already landing a fix: https://chromium-review.googlesource.com/c/chromium/src/+/969042

Reverting seems correct to me.

Doc forthcoming from dproy@ on how we can integration test things like this more effectively.

📍 Couldn't reproduce a difference.
https://pinpoint-dot-chromeperf.appspot.com/job/16b05db9440000

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

[scheduler] Use WorkerSchedulerProxy in DedicatedWorkerThread. by altimin@chromium.org
https://chromium.googlesource.com/chromium/src/+/053b619cf7ac1dd0ed6504e6e65da0e45d0a9d4e

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

The graphs have recovered.