We do intentionally catch up for all image animations after a tab switch. The behaviour had been in blink for a very long time and cc just continued to respect that.

I'm assuming the bug is about eliminating the catch up if the page went invisible? If so, it would be good to check the behavior of other browsers and decide based on that.

I've already checked the other browsers in the past. I also wrote a design doc about it and made a demo for people to try. I think need to work on improving the visibility of my work. :)

Previously, Firefox* and Edge didn't catch up.

I just checked again and now neither does Safari. Of these browsers, we're the only ones with this behavior.

I'll work on something to help with visibility and post it here later.



* Firefox does something interesting after it loops. It has decoded every frame at that point. That means catching up is now free if all the frame are cached. So Firefox then switches to a catchup mode. But on Firefox mobile (where presumably the cache budget is smaller) it won't switch. I assume Firefox's logic isn't actually to switch but instead to catchup if it is free.

Just to make sure I understood correctly, is the behaviour to not do catch up on Firefox, Edge and Safari only for when the image is not visible (tab switch or scrolled off the viewport), or also in the general case where its being displayed but the decode work can't keep up with the animation frame rate? I'm assuming its the former.

If all other vendors have stopped supporting this behaviour, then it makes sense for us to do the same. The implementation should be pretty simple in cc::ImageAnimationController. The |should_animate_from_drivers_|[1] flag in AnimationState is pulled from layers and set to true if the image is visible. You can check whether it was toggled to know whether catch up is necessary the next time the animation is ticked.

[1]: https://cs.chromium.org/chromium/src/cc/trees/image_animation_controller.h?g=0&l=182