Un-reachable images should be dropped from Image Decode Cache |
||||
Issue descriptionWhen we are dealing with an infinite-scrolling or image gallery type site, we can encounter cases where an image has been removed from the DOM. This image is no longer reachable, and will end up with a new ID / redecode even if it's re-added to the DOM. We should have a way to detect/remove these non-reachable images from the image decode cache. This is also somewhat true for images that have gone beyond the prepaint region, and may still be in the DOM but not in any potential painting. These images *may* be re-usable if they are scrolled back in, but (a) I'm not sure if this works, and (b) it may still not be a great memory trade-off. Both of the above are especially true for GPU Raster, where we are using real GPU resources. However, even in the unlocked-discardable case, deleting not-reachable images makes sense.
,
May 18 2017
cblume@, just wanted to clarify what you meant with ImageDecoder's cache being cleared. From what I understand, the decodes are keyed using ImageFrameGenerator and are purged when it is destroyed. Since blink::Image has a reference to it, it will keep it alive. So stuff will be cleared if the image is destroyed, but if it simply moves beyond pre-paint, it will still be there. A few cases I could think of were: 1) Since for static images blink only caches partial decodes till the image is completely loaded. This image could move outside the prepaint region. Nothing is going to trigger that decode to completion. 2) For animated GIFs, blink caches up to 2 frames. Those frames will still remain cached if we stop updating this image. Not to say that clearing them and causing a full re-decode is a better trade-off.
,
May 18 2017
,
May 21 2018
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jun 1 2018
|
||||
►
Sign in to add a comment |
||||
Comment 1 by cblume@chromium.org
, May 18 2017