Currently TextureManager moves a texture to the end of the list if hasTexture() is called. In the threaded compositing mode, TiledLayerChromium maintains a HashMap of tiles. In TiledLayerChromium::pushPropertiesTo(), it walks through all the tiles in the HashMap and check whether they are valid which calls hasTexture(). This means the order in the TextureManager's LRU list is affected by the order of the tile in the TiledLayerChromium's HashMap. e.g. when a page is scrolled down, we expect the furthest from the new revealed tiles will be reclaimed. Currently some tile in the middle can be reclaimed. The proposed fix is to only move a texture to the end of the list if protectTexture() is called.
Created attachment 117052 [details] Patch
Comment on attachment 117052 [details] Patch Looks reasonable, although a test would be nice. Enne?
This seems like a great change. That would certainly explain the "MRU"-like behavior that we've sometimes seen when scrolling.
Comment on attachment 117052 [details] Patch R=me then
Also if someone is feeling really ambitious and wants to write some unit tests for TextureManager's LRU-ness that would be awesome. I probably should have done this ages ago, but haven't got around to it :/
Comment on attachment 117052 [details] Patch Clearing flags on attachment: 117052 Committed r101586: <http://trac.webkit.org/changeset/101586>
All reviewed patches have been landed. Closing bug.