Scrolling planet.mozilla.org on a rMBP seems to require 150+ tiles. This doesn't interact well with our tile pool size of 50.

Dupe to bug 1221073?

I think even with the tile size increased we'd still be using too many tiles. I can still hit 64-66 outstanding tiles (with the cap removed) on planet.mozilla.org which is approximately 12 rMBP screens worth or 256 MB of memory. This isn't an insane amount but it's still a lot.

Is that with bug 1231168 applied? Short of shrinking the displayport is there anything else we can do here?

(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #3) > Is that with bug 1231168 applied? Short of shrinking the displayport is > there anything else we can do here? Yes. Both 1231168 and 1221073 applied. Should the the displayport be causing 12*screen size?

Tile aligning the display port can cause it to be significantly larger than we intend it to be. it might be worthwhile sometimes rile aligning inwards rather than outwards.

(In reply to Jeff Muizelaar [:jrmuizel] from comment #4) > Yes. Both 1231168 and 1221073 applied. Should the the displayport be causing > 12*screen size? Yeah, pretty much. The stationary x multiplier is 3.0 and the stationary y multiplier is 3.5, so (screen * 3.0) * (screen * 3.5) is 10.5x the screen size. With tile rounding it's probably close to 11x.

Actually wait that's only true on a page that's scrollable both vertically and horizontally. If the page is only scrollable vertically, it should only be 3.5x. Setting the apz.enlarge_displayport_when_clipped pref (defaults to false on desktop) will allow APZ to redistribute the unused horizontal space in the vertical direction, so if you have that set to true then you might get the 10.5x thing I mentioned above even on a vertical-only page. The other factor might be if you have multiple scrollframes on the page, and each is getting a displayport then you get the sum of all that.

planet.mozilla.org is scrollable in both directions

So that's pretty much worst-case scenario then. I think we can probably reduce the width of the displayport since it's relatively infrequent.

... but only after we have the checkerboarding measurement stuff in place :)

The tile pool decides whether to retain a tile in the pool based on the total number of tiles that exist (ones already in the pool, plus ones in-use for content). This means that once we have more in-use tiles than the pool size, we never recycle tiles and end up reallocating on scroll. I think instead we should only ever count the number of tiles waiting in the pool, so that we'd always be able to recycle a full row of tiles when scrolling (modulo ridiculous values for displayport or pool size). We'd still fail to recycle the full set of tiles when we need a full new set of tiles (tab switch?), but we'd still at least recycle the tile pool size worth which is the current behaviour. I'm not sure if we currently differentiate between short term tile pool spikes (like tab switch), vs long term growth (we have less layers than we did earlier and no longer need that many tiles), but we probably should.

Seems to me like most of this bug is covered by other more specific bugs.

I think I meant to close this bug with my last comment, on the basis that this bug doesn't really have anything actionable that's not covered by the other bugs.