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

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


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

mac-10_12_laptop_low_end-perf
mac-10_13_laptop_high_end-perf

blink_perf.paint - Benchmark documentation link:
  https://bit.ly/blink-perf-benchmarks

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/1005b4e2140000

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

gpu: Disable CCPR for OOP raster. by khushalsagar@chromium.org
https://chromium.googlesource.com/chromium/src/+/193eda157bdb1c66d9afdc9c54a36e0ccc249293
transform-changes: 2408 → 6500 (+4093)

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

Benchmark documentation link:
  https://bit.ly/blink-perf-benchmarks

This is interesting. I assumed changing the path renderer will be a purely gpu side change but it seems to be affecting paint timing!?

+chrishtr/pdr, does this measure anything past the paint stage in blink. My change should have only affected the work happening in the GPU process's main thread.

Looking at the trace of transform-changes.html with and without your change, the blink side is roughly the same performance-wise. For example, there are 15 beginframes in both, and the total time spent in the renderer is roughly the same (748ms before, 763ms after). I think the cause of this regression is somewhere else which is causing blink to be updated much less frequently.

Can you take a trace locally with more trace events enabled and compare with/without your change? I think this will show where the regression is.