Issue metadata
Sign in to add a comment
|
Jank while scrolling with large GIFs visible on screen |
||||||||||||||||||||||
Issue descriptionVersion: 54 OS: Windows 10 What steps will reproduce the problem? (1) Open https://cloud.googleblog.com/2016/09/all-together-now-introducing-G-Suite.html (2) Wait for page to load completely. (3) Scroll down so that the three GIFs are in view. What is the expected output? No jank while scrolling. What do you see instead? Scroll pauses for seconds at a time, see DevTools trace. Even when not scrolling there is high CPU usage, Chrome seems to be decoding images every single frame even after the animation has looped. In comparison Firefox has no problem scrolling while the GIFs are visible and uses much less CPU to render the animation.
,
Sep 30 2016
,
Oct 5 2016
,
Oct 5 2016
I am removing the duplicate because this is a slightly different case. When you scroll an animated image into view, we catch up the animation to where it should be. This means churning through all the frames needed to get there, which is very slow. So the scroll-into-view jank is different from regular animation jank. Also responding to #1 about how after the loop there is still high CPU usage: We purge decoded frames from the decoder after each frame. I believe (but need to double check) that once Blink has the frames it keeps them in its image cache. Perhaps Blink's image cache is going over its budget. Or perhaps Blink needs to know the duration of the frames and it gets it by requesting the next frame be decoded. I'll look into this. Or maybe my mental model of how Blink handles the image cache is wrong. I have already began pushing for us to not require images to maintain this sync. It is costly (as noticed by this bug) and the benefit might be very limited. Safari mobile and Edge desktop (I did not test Edge mobile) do not maintain sync.
,
Nov 8 2016
,
Jul 14 2017
|
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by f...@opera.com
, Sep 30 2016