Bug 73344 – [chromium] TextureManager LRU list is not fully honor the order tiles are used

• Component: New Bugs
• Status: RESOLVED FIXED

[Grace Kloba]

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.

[Grace Kloba]

Created attachment 117052 [details]
Patch

[James Robinson]

Comment on attachment 117052 [details]
Patch

Looks reasonable, although a test would be nice. Enne?

[Adrienne Walker]

This seems like a great change.  That would certainly explain the "MRU"-like behavior that we've sometimes seen when scrolling.

[James Robinson]

Comment on attachment 117052 [details]
Patch

R=me then

[James Robinson]

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 :/

[WebKit Review Bot]

Comment on attachment 117052 [details]
Patch

Clearing flags on attachment: 117052

Committed r101586: <http://trac.webkit.org/changeset/101586>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.