Related discussion: https://news.ycombinator.com/item?id=14087899

Not sure who to pass this on to. Help assigning this would be appreciated.

The image specifies a delay time of 20ms for each of its 10 frames. We have code [1] to defeat "annoying ads" which have very short delay time (e.g. 0ms). For anything <= 10ms, we increase the delay time up to 100ms. This matches Firefox (unless Firefox has changed since then) and others (same). If you want to read all the details, there's a trail of bugs starting from the link in the Chromium comment [2].

Interestingly, there was a time when we forced anything <= 50ms to 100ms. That resulted in [2]. We've gone back to 10ms, which is consistent with other browsers (minus IE [3]), though exact choice seems to have been somewhat arbitrary over time [4]. (Sounds like the specific behavior/times originated in Opera, though I haven't found Opera's justification of the specifics.)

Regarding "Chromium should cap the animation FPS to 60 FPS. I believe that animating a tiny gif on i7-6700HQ should take only a tiny portion of the CPU power." it sounds like we don't want to change this behavior, which might make this gif work "better" but break others, and it would make us inconsistent with other browsers. It has been suggested that this should be part of the HTML spec, but it sounds like that is not going to happen [5].

To sum up - this behavior is not likely to change.

That said, it's still possible we could display this image without consuming so much CPU. DeferredImageDecoder will only cache a frame if (DeferredImageDecoder thinks) the frame will (/might) be used for a future frame. (I don't know what is cached by layers above.) This image has 10 32x32 frames, so we could potentially keep all frames cached, although this is a tradeoff in memory, and we really need a heuristic to determine the right tradeoff.

[1] https://chromium.googlesource.com/chromium/src/+/bed45cf2cce0a3474ef04a1e2fca2e5dc77e1b2c/third_party/WebKit/Source/platform/graphics/DeferredImageDecoder.cpp#239
[2] https://bugs.webkit.org/show_bug.cgi?id=36082
[3] https://bugs.webkit.org/show_bug.cgi?id=26455
[4] https://bugzilla.mozilla.org/show_bug.cgi?id=440882
[5] https://bugs.webkit.org/show_bug.cgi?id=36082#c6

Thank you very much for your informative response, it provides a lot of insight. Also thank you for Chromium - I love the browser and its performance. Yet, please allow me to respectfully disagree.

The main idea is that a 1920x1080x60FPS video decoder is totally fine to use 1-2 cores to decode frames. On the other side, as an user, I find it hard to believe that a 32x32x50FPS dancing parrot eats approximately the same CPU power. I guess there is a technical reason behind that, which is not visible at first sight. Anyway, opening a Slack page with all of those animated gifs will basically make the battery run out in one hour.

If I may, I'd have a couple of (silly) suggestions.

To work around the half-speed play [2] would it be possible to drop frames until the gif speed reaches 50 FPS? Perhaps for small gifs it would be feasible to re-encode them while dropping frames, either to gif, or to a mp4, whichever is easier to prototype and more cpu-effective.

-IMC label, that is only for video codecs.

Sorry, meant image codecs.

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

This issue is still present; it causes extreme battery drain just by having a dancing parrot opened in slack. By fixing this on every browser you can save megawatts of energy in total. Think of the planet. Think of the coolers not having to spin. Think of the parrot being happy not being an energy waster. Think green - kill the parrot... Erm kill the bug! :)

Reading previous comments, seems like the only way around this is modifying caching behavior somehow.

Khushal: could you take a look here and see if all the gif frames are cached and look at a trace and see if anything else looks amiss?

This might just be "running Chrome at 60fps for an hour is expensive", in which case this specific case might be WontFix because it fits into our larger power-reducing efforts.

 Issue 671138  has been merged into this issue.

The complete GIF is cached in memory so there aren't any repeated decodes happening. And now since we've removed the paint step for these animations, the cost you're seeing is just what it takes to re-raster and composite at 60 fps. Note that with partial raster, we're also only re-rasterizing just the size of the image. So this is a WontFix.