- Load https://greensock.com/js/speed.html
- Select "Web Animations (translate/scale)"
- Select 1000 for the number dots.
- Hit start
- Watch the fps drop steadily
In bug 1253476 I am making us not accumulate filling animations forever which makes this faster, but it still drops.
Example profile after letting it run until the fps drops to 5fps: http://bit.ly/2HGqeqy
After that bug lands I'd like to try and optimize this further. In particular, some initial profiling suggests the following could help:
Try to avoid running
CompactFillEffect::BuildProperties every time we resolve style. This is needed since in theory the updated style could affect the computed values we're interpolating between. However, we could probably be smarter and skip doing this at least some of the time (even if it just means, e.g. never doing it for opacity, or when we have pixel-based transform values etc.)
AnimationEffect::InEffect. This is called a lot and ends up calling
GetComputedTiming() which does a lot of unrelated calculations when all we really care about is: "is the progress null or not"? There's probably a way to factor out part of
GetComputedTiming() to simply answer the question of whether or not the progress is null.
There may well be others but those seems like two of the most obvious ones.
I also notice that we spend quite a bit of time setting performance warnings (since the dots in the test case are too small to be layerized). Perhaps there's some way to optimize work there?
If I drop the
fill: "forwards" from the test case then the fps is fairly stable (it drops from time to time but then eventually recovers). So this bug is really about optimizing the filling machinery to bring the stable state fps closer to the initial fps.