I believe we already do this inside the ImageDecoders.
Presumably, you're talking about CC's image cache?

Yeah exactly. Right now in cc, we treat each frame as a distinct unique image, which is not optimal.

I can have a look at this, if no one has started.

Just to check, how big should the gif be, having how may frames ? that we consider reusing previous frames ? 
Or do it for all animated images ?

It looks like while animating, in cc it will cache once for each frame.

For the compositor caches, the metric that I think we should start with is when the number of frames times the size of each frame (ie the total size of the whole gif) exceeds the gpu memory limit, then we don't keep the frames uploaded in cache.

We still want to keep them around in discardable, since we don't know whether discardable would evict them. We do control the gpu memory, so in cases where it certainly won't fit in its totality, then we can just keep the last two frames (one for the active tree and one for the pending tree).

The steps here are:
1. Add the number of frames to the paint image (https://codereview.chromium.org/2883593002/)
2. Make sure that we have access to correct paint image in the caches (I think khushalsagar is maybe looking at this?)
3. Add some sort of tracking from PaintImage id to SkImage id in the caches, which allows us to find which frames are related to the same gif
4. Evict things

I think 2 requires some fair bit of plumbing to get the correct PaintImage id from all sources into the cache so frames/SkImages for a gif can be tied back to it.
https://bugs.chromium.org/p/chromium/issues/detail?id=722559 is tracking that.

Thanks Vlad.

I had in-fact also plumbed the current frame number from BitmapImage for using in cache eviction logic.
I was thinking if we could add the frame number in ImageData, to be used in cache, so that in GIF with N number of frames, we can evict from 1 till N-2.
AnimationType could help us identify the whether current image is animated.
But, yes whether all the frames are from same GIF is not straight forward as khushalsagar@ pointed.
But do we need the info ? If we evict the current multi frame GIF from 1 to N-2 shouldn't it be good ? 

I may be totally missing something here though.

I think the issue is that we don't know what gif the frames belong to. Right now, each frame is essentially an SkImage which has some uniqueID but each frame gets a new id. That's why we're adding PaintImage, so that the stable id of the paint image could be used to tie the frames together. However, the way we're discovering the images right now causes us to create a new PaintImage every time, which is not useful. We want to plumb the original PaintImage that blink gave us initially.

OK, i have started working on plumbing the right PaintImage ID to cc, https://codereview.chromium.org/2926513003/