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

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


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

chromium-rel-mac11-air
chromium-rel-mac11-pro
chromium-rel-mac12
chromium-rel-win10
chromium-rel-win7-dual
chromium-rel-win8-dual

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/14ccd6ed440000

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

Fix compositor thread name by altimin@chromium.org
https://chromium.googlesource.com/chromium/src/+/826afc1b01683f467bdaf535e970c084a8d73bf3

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

This bug is likely too old to take any action on, but renaming the compositor thread is almost certainly not responsible for whatever power regression we're seeing. Going to launch a bisect on the power metric instead of the buffering metric this time.

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/12b2cd22240000

(Specifically, I'm interested to see if this is a power regression caught by the BattOr but not any CPU-specific metrics)

There was a problem that metrics failed to compute and returned 0 due to incorrect metric name. The linked patch fixed this, therefore causing "regression" (from 0 to real value). 

I've taken a look at a number of graphs and it seems that they've reverted to normal in the meantime.

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

Closing this as unable to repro