Currently layers.tile-max-pool-size is set to 50. I think this is wildly optimistic. On a modern smartphone you can expect a screen resolution of 1440x2560, for which we'll have a tile size of 512x512. On a simple page that only scrolls vertically we might get a display port of 1440x7168, or 42 tiles. Add some more tiles for low-res, and we've blown our limit. Plus the reality is that most sites are somewhat more complex than that. Although I'm all too aware of us sometimes over-layerising, I don't think a couple scrollable layers is unreasonable for a web site. As I understand it, if the number of clients in use is greater than the pool size, every time we scroll TextureClients will be destroyed and new ones created? In practice I'm not sure what the impact of this is - a shmem and gpu texture deallocation and allocation? I'd hope since the textures are all the same size this wouldn't cause any fragmentation, but there is presumably some cost to it that would better be avoided? What do other people think? (cc'ed some people who might have an opinion / have committed to TextureClientPool.cpp)
I think that limit was put in place in the old days of small screens and it's very likely that it needs to be increased now.
Yeah, I noticed the 50 tile pool size too, and filed bug 1182665. Someone (you!) should first figure out of the pool helps us with allocation time at all. If it doesn't, it's just wasting memory anyway and we should stop using it. If it helps, then we probably need to increase the size.
Measuring the allocation costs seems worthwhile, but it's definitely shown up in the past. I can think of at least two use cases we want to the pool to help with: * When scrolling, making sure that the tiles that got scrolled out of view get reused for content that just scrolled into view. * When navigating to a new page, recycling the full displayport worth of tiles. Both of these cases only require tiles to sit in the pool for a very short period of time. Maybe we should change the tile pool to count number of tiles free (rather than total allocated), allow huge numbers of tiles for short period, and use a timer callback to shrink the tile pool down to a small number (or none) if they don't get used again. We might need to flush the tile pool ahead of schedule if we get a memory-pressure event.
The mobile devices were really driving this, and given the sizes of the devices that were in play, we just couldn't afford to have a lot of tiles sitting around. The allocation cost was definitely showing up on those B2G devices, but from I recall, not really showing up on desktop. I'm intrigued by the idea of tracking unused tiles instead and allowing higher peak usage. For this to be a worthwhile effort, we need to identify devices/platforms that we care about, that have slow (enough) allocation, and lots of space. In the example in comment 0, each tile is 1M, and once you go double buffered, 2M (so to speak), so how many can we afford to have? Seems like we need more numbers here.
I remember wanting to know in Orlando why we track total tiles instead of unused ones as that seems like the more obvious thing to do. I don't remember if I found out the answer or what the answer was.
Should we add a telemetry probe to measure what the tile usage is in the wild?
A telemetry probe sounds like a good idea if we want some real numbers. Without that all I can really comment on is my experience: ~80 is incredibly normal. I often see ~200, but I'm often looking for sites which use a lot of memory. On high-end devices we don't seem to OOM till around 500, but that doesn't mean we should ever have that many let alone on less capable devices. I think Matt's idea in comment 3 makes a lot of sense. Having a small number of unused tiles in the pool in the steady state would help the initial scroll. (Zero would mean we need to allocate extra when we first scroll as returning the tiles is deferred to the end of the transaction? However maybe that's a worthwhile tradeoff.) And if we keep unlimited tiles around for a few seconds when switching tabs, it's no worse memory-wise than if the user had kept the first tab open a few seconds longer?
Closing, no longer an issue since bug 1279341 took care of this problem.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.