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

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


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

mac-10_12_laptop_low_end-perf
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/10f2643ce40000

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

[media] Reland: Fix video to canvas GPU-CPU race. by sandersd@chromium.org
https://chromium.googlesource.com/chromium/src/+/930cc1d5f861d51d4544f5ea60e73c33d8f2cdc8
queueing_durations: 0.2057 → 1.316 (+1.11)

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

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

I didn't expect a significant regression for most cases, but the CL in question did add heavier synchronization to the buffers used. Apparently camera->WebGL is one of the difficult cases.

Possibly the pool is too small for the time it now takes buffers to be returned to it. In any case the CL will not be reverted for this.