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

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


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

android-nexus6

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/16bf058e440000

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

Prevent compositing empty-sized iframes by bokan@chromium.org
https://chromium.googlesource.com/chromium/src/+/50d82505c50363ec5ab003fdbbf9d2f706114ac2

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

 Issue 821398  has been merged into this issue.

 Issue 821442  has been merged into this issue.

 Issue 821783  has been merged into this issue.

 Issue 821798  has been merged into this issue.

 Issue 821797  has been merged into this issue.

Update: finally managed to get a local repro - Android version is decisive: repros on L but not on my N device.

tl;dr - I think this is WontFix. The "regression" is really a "back to normal" before we enabled RLS (also, more recent Android versions seem to optimize this out). Explanation:

Before we enabled RLS, an empty iframe would not be considered scrollable so we wouldn't composite it. When we turned on RLS, we had a bug (fixed in  issue 811438 ) where these empty iframes suddenly became considered scrollable - causing them to composite. Fixing the bug means we went back to not compositing these empty iframes. The regression is counter-intuitive though - we avoid compositing an iframe and our GPU memory usage goes up. In the regressed story (spychase), we have a DOM tree that looks roughly like:

HTML 412x603 (composited)
  CANVAS 402x603
  DIV 402x603 (composited)
    IFRAME(A) 320x100
      IFRAME(B) 0x0

In this arrangement, the iframe A isn't composited so it gets rastered into it's containing layer which is the DIV of size 402x603. Before my "fix", iframe B would be composited by accident which causes A to require compositing so it rasters into its own layer of size 320x100, smaller than the layer in the previous scenario. As far as I can tell, the DIV doesn't paint anything of its own so compositing the iframe causes us to allocate a larger GPU buffer.

chrishtr@: Is this a known issue? Assuming I got this right, perhaps there's an opportunity to optimize for memory here by rastering into the smallest possible layer? Anyway, given that this takes us back to pre-RLS levels, can I WontFix this?

ping, chrishtr@, WDYT?

Sorry for the delay.

If DIV doesn't paint anything, then the reason more memory is used is
that previously DIV's cc::Layer used a solid color optimization, which saves
a lot of memory.

I agree that this is WontFix. This kind of situation happens often, and is
not really possible to optimize around.

Issue 821434 has been merged into this issue.

Issue 821436 has been merged into this issue.

Issue 821433 has been merged into this issue.

Issue 821432 has been merged into this issue.