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

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


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

mac-10_13_laptop_high_end-perf

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

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/10c3284de40000

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

Use SharedImageInterface in ZeroCopyRasterBufferProvider by piman@chromium.org
https://chromium.googlesource.com/chromium/src/+/e5a2101affba7a813731b399a9e102b86a7f27c6
tasks_per_frame_total_all: 84.46 → 103 (+18.52)

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

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

This CL is expected to increase the number of tasks on the GPU main thread, as it breaks down command buffer work (scheduled as a bloc) into individual tasks, however it shouldn't be a significant performance difference (CPU time changes within the noise), and power-wise those tasks are enqueued at the same time (i.e. shouldn't translate into more wakeups).
->wontfix.

 Issue 903760  has been merged into this issue.