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

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


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

linux-perf

media.desktop - Benchmark documentation link:
  None

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/136f3530e40000

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

Use SharedImage for HUD layer and one copy raster by backer@chromium.org
https://chromium.googlesource.com/chromium/src/+/e29d023ec416e0931584cb4c6daaa478cd36b478
cpu_time_percentage: 0.08505 → 0.09023 (+0.005182)

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

Benchmark documentation link:
  None

I attempted to run this locally on my linux dev box with no joy. It is unable to to load the video resource.

That said, I investigated a similar bug last week: https://bugs.chromium.org/p/chromium/issues/detail?id=891356

That bug got "WONT FIX"ed because there is flakiness in the CPU measurement (it doesn't properly account for frequency scaling).

Without a local repro, I can't verify 100% (e.g. turn off frequency scaling locally), but I'm fairly confident.

Please follow dialogue on https://bugs.chromium.org/p/chromium/issues/detail?id=892147 for properly accounting for frequency scaling.

 Issue 892843  has been merged into this issue.