So basically if something moves out of the paintable region, we will evict it from the cache?

Re #1 - it's debatable whether it's better to do "something moves out of the paintable region" or "something is removed from the DOM such that it could never be paintable (regardless of position on page)"

The first option will purge things more aggressively, but may result in worse performance on very large pages.

BTW there is also a fine difference between DOM-reachability and cc-layer-reachability.

It is a common practice to use a invisible element (opacity:0 or clipped to 0x0) to prefetch sprites. Those are reachable from DOM but not necessarily painted into display lists.

I think this essentially comes down to just trimming as much as we think we should trim. In terms of paintability, I think that's somewhat sufficient since when something falls out of prepaint (ie non-now raster), and then falls out of even being painted (ie not in the paint buffer), that's a decent signal that this thing might not be visible for some time. Of course we'll have cases where we then immediately need the image (like home/end buttons type of thing), but I think these would be rare.

It's a good point that sometimes there's something that's not painted but right there in the dom. I would still be reluctant to keep images cached if we can't find them in the paint buffer anymore though. Not sure if people have other thoughts though. 

+sohanjg, in case this is something you're interested in working on (per discussion with vmpstr@).

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/676e8ccff70ea1c30674e8f97e38296bdd1af8fc

commit 676e8ccff70ea1c30674e8f97e38296bdd1af8fc
Author: sohan.jyoti <sohan.jyoti@huawei.com>
Date: Tue Jun 20 21:26:23 2017

cc: Interface to evict images from cc image decode cache.

This adds interface to enable eviction of images from
image decode cache in cc. This CL sets up the interface
and eviction logic in gpu image decode cache. A follow
up would handle the sw cache eviction.

BUG= 730784 
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel

Review-Url: https://codereview.chromium.org/2945813002
Cr-Commit-Position: refs/heads/master@{#480961}

[modify] https://crrev.com/676e8ccff70ea1c30674e8f97e38296bdd1af8fc/cc/raster/image_hijack_canvas_unittest.cc
[modify] https://crrev.com/676e8ccff70ea1c30674e8f97e38296bdd1af8fc/cc/tiles/gpu_image_decode_cache.cc
[modify] https://crrev.com/676e8ccff70ea1c30674e8f97e38296bdd1af8fc/cc/tiles/gpu_image_decode_cache.h
[modify] https://crrev.com/676e8ccff70ea1c30674e8f97e38296bdd1af8fc/cc/tiles/gpu_image_decode_cache_unittest.cc
[modify] https://crrev.com/676e8ccff70ea1c30674e8f97e38296bdd1af8fc/cc/tiles/image_controller_unittest.cc
[modify] https://crrev.com/676e8ccff70ea1c30674e8f97e38296bdd1af8fc/cc/tiles/image_decode_cache.h
[modify] https://crrev.com/676e8ccff70ea1c30674e8f97e38296bdd1af8fc/cc/tiles/software_image_decode_cache.cc
[modify] https://crrev.com/676e8ccff70ea1c30674e8f97e38296bdd1af8fc/cc/tiles/software_image_decode_cache.h

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

Is there more work that needs to be done here?

We considered a callback based approach to let the cache know when there were no references to a PaintImage so it can purge any associated data. But it turned out to be too complicated and not worth the effort.