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

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


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

mac-10_13_laptop_high_end-perf

rasterize_and_record_micro.top_25 - Benchmark documentation link:
  None

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/179535b8140000

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

Removing the kInlineTransform compositing reason by masonfreed@chromium.org
https://chromium.googlesource.com/chromium/src/+/f6e075c54c8bc6130d49c09ad3df6944376ccba4
rasterize_time: 5.888 → 6.008 (+0.1209)

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

Benchmark documentation link:
  None

Based on the magnitude of the increase, and the characteristics of the test page, we would like to WontFix this regression. As described below, this CL is expected to cause, in some cases, more rasterization. This is what has regressed here.

The referenced CL removes an optimization that previously caused inline transforms to force  the styled layer to be composited. It was the cause of at least one bug (crbug.com/812166) and this optimization will not apply once Composite After Paint is implemented. The effect of the patch should be to cause fewer composited layers overall, and potentially more rasterization. We believe it will be a net win; however, it may cause some small regressions, particularly when more rasterization is required.

 Issue 911204  has been merged into this issue.

 Issue 911554  has been merged into this issue.