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

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


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

android-nexus5

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/1184eeee440000

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

Prevent scroll contents being smaller than clip by bokan@chromium.org
https://chromium.googlesource.com/chromium/src/+/cead2e78a8e7e9acba07fd4f3d6ab2c9b3713e18

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

I looked into this a bit - I think it's expected since we've made the scrolling contents layer taller. In the gmail story, for example, the scrolling contents layer previously had about 400px less in height than the clipping layer. Mine and skobes@' patches make them equal which is necessary for correct pinch/scroll functioning in CC (the scrolling contents layer is now the outer viewport) and painting of content. e.g., if I add a bottom-fixed, uncomposited element to the gmail page, we would previously (reverting mine and skobes' patches) clip it out erroneously so the fix improves correctness.

+vmpstr@ as owner of the benchmark: taking the gmail case as an example, it doesn't look like we actually have to rasterize any page content in that newly region at the bottom of the page, it's all empty. Is a small bump here expected? I'm guessing we need to do more work at raster to clear these extra pixels?

I think a larger visible region means more rasterization time because more content is being rasterized.  I think this should just be considered a new baseline and WontFix.

Ok, thanks!

 Issue 813995  has been merged into this issue.

 Issue 821396  has been merged into this issue.