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

CT shows overall progression (-0.7%) of rasterize_time [1], and Finch shows overall progression of Gpu rasterization but slight regression of Software rasterization [2].

[1] https://ct.skia.org/results/cluster-telemetry/tasks/chromium_perf_runs/wangxianzhu-20180406023648/html/index.html
[2] https://uma.googleplex.com/p/chrome/variations/?sid=ce3614a88eaa8a4a60cb134e7aa644a2

I'm not giving this bug high priority, but by looking into the details of the test cases, we might find opportunities to optimize.

At least yahoogames, the regression happens when the page contains a lot of dom like the following:
  <div style="overflow: hidden">
    ABC
  </div>

In SPv1, the above dom doesn't create any clip, while in SPv175 we create OverflowClip and emit Save/ClipRect/.../Restore.

We should either avoid OverflowClip node or issue OverflowClip bug avoid Save/ClipRect/.../Restore sequence in the case. The former seems simpler to implement.

Another source of regression is about empty effect:
  <div style="opacity: 0.5">
    ... <!-- which paints nothing -->
  </div>
we will still output SaveLayer/Restore which is expensive.

This one is actually more important than #c3.

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/12537d44c40000

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/17878c24c40000

📍 Job complete. See results below.
https://pinpoint-dot-chromeperf.appspot.com/job/17878c24c40000

📍 Job complete. See results below.
https://pinpoint-dot-chromeperf.appspot.com/job/12537d44c40000

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/14c95d9cc40000

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/10794254c40000

📍 Job complete. See results below.
https://pinpoint-dot-chromeperf.appspot.com/job/14c95d9cc40000

📍 Job complete. See results below.
https://pinpoint-dot-chromeperf.appspot.com/job/10794254c40000

Turned out that neither #c3 nor #c4 is the root cause of rasteriza_time regression. The root cause is actually a bug of SPv1 causing wrong visual rect of some filter effects which were not applied correctly. The "regressin" is actually the cpu time used to rasterize the correct filter effects.

However, fixing #c3 (https://chromium-review.googlesource.com/c/chromium/src/+/1001752, try job result in #c12) will actually improve record_time because we'll deal with less paint chunks and clip states. Will land it for general performance  bug 803867 .

#c4 seems to affect neither record_time nor rasterize_time. When a PaintOpBuffer is rasterized, we'll optimize by removing unnecessary operations, so the redundant operations don't matter much to performance.