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

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


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

win-high-dpi

Started bisect job https://chromeperf.appspot.com/buildbucket_job_status/8971091325224501216

=== BISECT JOB RESULTS ===
NO Perf regression found

Bisect Details
  Configuration: winx64_high_dpi_perf_bisect
  Benchmark    : media.tough_video_cases_tbmv2
  Metric       : css_animation:power_avg/video.html?src_crowd720_vp9.webm

Revision             Result                  N
chromium@494018      8.54247 +- 3.22892      21      good
chromium@494047      8.48254 +- 1.16778      21      bad

To Run This Test
  src/tools/perf/run_benchmark -v --browser=release_x64 --output-format=chartjson --upload-results --pageset-repeat=1 --also-run-disabled-tests --story-filter=video.html.src.crowd720.vp9.webm media.tough_video_cases_tbmv2

More information on addressing performance regressions:
  http://g.co/ChromePerformanceRegressions

Debug information about this bisect:
  https://chromeperf.appspot.com/buildbucket_job_status/8971091325224501216


For feedback, file a bug with component Speed>Bisection

+johnchen, crouleau: both here and in bugs  753653  and  740167 , there is a clear ~20% jump in the graph that the bisect can't reproduce. Only happens on this Windows HiDPI laptop. Can one of you look at the traces and see if there's any clue what might be causing these shifts?

Doubtful it's worth looking at the Chrome trace if bisect doesn't notice anything: if bisect doesn't figure it out then that means that the changes to Chrome aren't the cause of the additional power usage, so therefore it must be something else (like additional background processes running or hardware problems). Chrome traces only give information about Chrome, so they won't be very helpful in figuring out an OS-level problem.

+charliea has done a lot of work looking into this type of thing.

Whoops, was looking at the end of the metric ("video.html?src_tulip2.ogg_type_audio_seek", etc) and seeing the word seek and thinking these are about seek times. Agreed I really hope the work Charlie is doing on noise reduction will fix these. I'm going to close both bugs as WontFix.