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

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


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

mac-10_12_laptop_low_end-perf

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

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/11e328eae40000

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

Remove FlushForDriverCrashWorkaround by ccameron@chromium.org
https://chromium.googlesource.com/chromium/src/+/b0587ce32c778a4fcc2cb5802d3eabc44e315b24
TabCapturePerformance_comp_gpu: 21.18 → 25.74 (+4.562)

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

+vmiura & +kbr as FYI -- apparently *removing* the excessive glFlush causes performance regressions.

(WontFix, of course).

Interesting. Before James' transfer buffer resizing changes, there were probably frequent enough flushes during Chrome's regular rendering operations to keep the overlap high between the renderer and GPU processes. frame_times/motion_mark_canvas_fill_shapes in rendering.desktop and TabCapturePerformance_comp_gpu/Capture in performance_browser_tests were the two benchmarks affected here.

fserb@ fyi for the canvas regressions.

The tab capture metric looks like it just reverted to it's long term value before this workaround landed.