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

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


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

chromium-rel-mac12

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/15ec188c040000

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

Round the scroll offset synced back to main thread instead of flooring
By yigu@chromium.org · Tue Dec 05 15:49:54 2017
chromium @ a3ce2d3110a3f9177a41935daadd43ede72db553

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

This may be expected from us compositing more elements on low dpi as that CL also re-enabled compositing opaque fixed position elements. Yi, can you verify this is the case?

Investigating the website https://king.com/game/alphabetty

BTW keep in mind the graph also exhibits a large downwards spike after the regression.

There are lots of elements getting composited due to the change which caused the regression. This should be expected.

So this regression is intended from your change? Please mark as WontFix if that's the case.

 Issue 792930  has been merged into this issue.

 Issue 792922  has been merged into this issue.

This is a pretty significant regression that is wontfixed because of an untested hypothesis. Who is the right person to test this hypothesis?

I investigated the test page (https://king.com/play/alphabetty) before I closed the bug. On the page there are some elements that were not but are composited now due to the change we made therefore the memory cost increase is expected.

Erik - should we wontfix this?

 Issue 792938  has been merged into this issue.

As per c#13, closing as WontFix.