Open Bug 1524155 Opened 1 year ago Updated 1 year ago

Optimize for Web Animations


(Core :: DOM: Animation, enhancement, P3)





(Reporter: birtles, Unassigned)




  1. Load
  2. Select "Web Animations (translate/scale)"
  3. Select 1000 for the number dots.
  4. Hit start
  5. 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:

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.)

  • Optimize 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.

You need to log in before you can comment on or make changes to this bug.