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

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


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

android-nexus5
android-nexus5X
android-nexus7v2
android-one

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/12be3b6d840000

😿 Pinpoint job stopped with an error.
https://pinpoint-dot-chromeperf.appspot.com/job/12be3b6d840000

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/12b0e035840000

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

Enable root layer scrolling. by skobes@chromium.org
https://chromium.googlesource.com/chromium/src/+/96f85b68747a679ea1ac4cd05d6743ae5f7142b7

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

This regression appears to have recovered after recent patches. Will watch
the bot for a little longer to verify.

 Issue 811430  has been merged into this issue.

Some of the graphs in the bug report have recovered but others still haven't. Will take a closer look.

+pdr@, you mentioned you're looking at a similar input latency issue?

Yeah, I'm looking into  https://crbug.com/818772  which I have partially explained. It's very possible these are two different bugs. Just keep an eye on PaintLayerClipper and if this test is a regression because of that, we can dupe it.

The input latency is a symptom of longer frame times it seems (latency of a GSU is measured relative to when the changed scroll offset is swapped to screen). From what I can see in traces, the longer DrawFrames is that we have many more layers. Sure enough, printing out the layer tree shows we have more than twice as many layers when RLS is turned on.

First look shows that we're compositing iFrames with the reason "iFrame" which only happens in RLS. I'll take a closer look tomorrow but I've attached the layer tree printouts if someone wants to take a look before that.

Deleted: output.log 112 KB

output.log 112 KB View Download

Deleted: output-rls-off.log 61.6 KB

output-rls-off.log 61.6 KB View Download

Tracked this down to the fact that we now add overflow to a LayoutView in an empty frame in LayoutBlock::ComputeOverflow because the LayoutView now HasOverflowClip(). This causes CompositingReasonUpdater to see this as the iframe being scrollable and causes it to composite a pile of extra layers on this page. Removing this overflow addition removes the perf regression.

I'm still trying to understand what this code is doing and what the best fix is but I should have a fix up today/tomorrow.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/50d82505c50363ec5ab003fdbbf9d2f706114ac2

commit 50d82505c50363ec5ab003fdbbf9d2f706114ac2
Author: David Bokan <bokan@chromium.org>
Date: Thu Mar 08 01:01:20 2018

Prevent compositing empty-sized iframes

Turning on root-layer-scrolls caused the number of layers on the
worldjournal story to almost double, causing regressions on many
metrics. The reason for these extra layers is because we were now
compositing iframes where we weren't before.

These iframes have empty sizes: 0x0 but, when RLS is enabled, the
LayoutView computes a non-empty layout overflow rect in
LayoutBlock::ComputeOverflow (due to default margins on an empty page).
The reason this differs based on RLS is because LayoutView has an
overflow clip only when RLS is turned on. Thus, without RLS,
ComputeOverflow doesn't add overflow from the old_client_after_edge and
the LayoutView never gets any overflow. No overflow means DocumentRect
in LocalFrameView::ScrollingReasons() does not exceed the empty
VisibleContentRect size and we return kNotScrollableNoOverflow. With
RLS this method returns kScrollable and we blindly mark it as needing
compositing.

The fix in this CL is to check that the iframe has some size in addition
to being scrollable before we composite it.

Bug:  811438 
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2
Change-Id: Iae82d124337088531ef94acac1e7383f08b852b5
Reviewed-on: https://chromium-review.googlesource.com/953332
Reviewed-by: Chris Harrelson <chrishtr@chromium.org>
Reviewed-by: Steve Kobes <skobes@chromium.org>
Commit-Queue: David Bokan <bokan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#541663}
[modify] https://crrev.com/50d82505c50363ec5ab003fdbbf9d2f706114ac2/third_party/WebKit/Source/core/frame/LocalFrameView.cpp
[modify] https://crrev.com/50d82505c50363ec5ab003fdbbf9d2f706114ac2/third_party/WebKit/Source/core/paint/compositing/CompositingReasonFinder.cpp
[modify] https://crrev.com/50d82505c50363ec5ab003fdbbf9d2f706114ac2/third_party/WebKit/Source/core/paint/compositing/CompositingReasonFinderTest.cpp

The change hasn't cycled through the perf bots - still waiting to see results. Assuming it works - this will need a merge to 66 so I'm leaving this open.

Ok, looks like the bots have been working fine but the story name has changed so the graphs in the link above are no longer getting the newest data.

Here's a collection of the updated graph names showing the regression is fixed (along with one old graph for comparison). 

https://chromeperf.appspot.com/report?sid=7a16b8099ac4886e22c533ce94a9db8634f88437b823ce4b6c4d70f01d9779c0

Requesting merge to M66

Pls apply appropriate OSs label.

This applies on all Blink platforms.

Your change meets the bar and is auto-approved for M66. Please go ahead and merge the CL to branch 3359 manually. Please contact milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), josafat@(ChromeOS), abdulsyed@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/09017524c90ade8e722677f5b0b67d53efdb4a71

commit 09017524c90ade8e722677f5b0b67d53efdb4a71
Author: David Bokan <bokan@chromium.org>
Date: Mon Mar 12 13:31:55 2018

Prevent compositing empty-sized iframes

Turning on root-layer-scrolls caused the number of layers on the
worldjournal story to almost double, causing regressions on many
metrics. The reason for these extra layers is because we were now
compositing iframes where we weren't before.

These iframes have empty sizes: 0x0 but, when RLS is enabled, the
LayoutView computes a non-empty layout overflow rect in
LayoutBlock::ComputeOverflow (due to default margins on an empty page).
The reason this differs based on RLS is because LayoutView has an
overflow clip only when RLS is turned on. Thus, without RLS,
ComputeOverflow doesn't add overflow from the old_client_after_edge and
the LayoutView never gets any overflow. No overflow means DocumentRect
in LocalFrameView::ScrollingReasons() does not exceed the empty
VisibleContentRect size and we return kNotScrollableNoOverflow. With
RLS this method returns kScrollable and we blindly mark it as needing
compositing.

The fix in this CL is to check that the iframe has some size in addition
to being scrollable before we composite it.

Bug:  811438 
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2
Change-Id: Iae82d124337088531ef94acac1e7383f08b852b5
Reviewed-on: https://chromium-review.googlesource.com/953332
Reviewed-by: Chris Harrelson <chrishtr@chromium.org>
Reviewed-by: Steve Kobes <skobes@chromium.org>
Commit-Queue: David Bokan <bokan@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#541663}(cherry picked from commit 50d82505c50363ec5ab003fdbbf9d2f706114ac2)
Reviewed-on: https://chromium-review.googlesource.com/958006
Reviewed-by: David Bokan <bokan@chromium.org>
Cr-Commit-Position: refs/branch-heads/3359@{#160}
Cr-Branched-From: 66afc5e5d10127546cc4b98b9117aff588b5e66b-refs/heads/master@{#540276}
[modify] https://crrev.com/09017524c90ade8e722677f5b0b67d53efdb4a71/third_party/WebKit/Source/core/frame/LocalFrameView.cpp
[modify] https://crrev.com/09017524c90ade8e722677f5b0b67d53efdb4a71/third_party/WebKit/Source/core/paint/compositing/CompositingReasonFinder.cpp
[modify] https://crrev.com/09017524c90ade8e722677f5b0b67d53efdb4a71/third_party/WebKit/Source/core/paint/compositing/CompositingReasonFinderTest.cpp