0

What are the Performance/Efficiency implications of updating a Web Animation's currentTime property continuously within milliseconds?

What I would like to do is tie a web animation's current point in its timeframe to the user panning their finger across the screen. Normally, this is done with calling requestAnimationFrame from a pointer move event and setting the css properties directly on the element. But, I'd like to use web animations instead.

let animatedObj = animatedEl.animate(props, timing)
animatedObj.pause()

el.addEventListener('pointermove', (event) => {
  animatedObj.currentTime = (.... percentage of pointer position ....)
})

But is it more prone to jank or battery energy intensive than requestAnimationFrame and setting css properties directly? Is setting currentTime not designed for continually updating within ms? Would it be better to use requestAnimationFrame while still setting the animation's currentTime?

risingtiger
  • 851
  • 1
  • 11
  • 21

1 Answers1

2

It's quite acceptable to set the currentTime in this fashion and theoretically should be fractionally more performant than setting the CSS properties directly since the CSS property values don't need to be re-parsed on each frame. In practice, however, the difference should be negligible. By using Web Animations you can also make use of easing effects and the like which might be an advantage.

I assume animatedObj in your example is paused. By pausing it, you can ensure it will not unnecessarily trigger style updates when the pan position does not change.

By using requestAnimationFrame you ensure that your callback is run before style is updated (but after the animation time has been updated) which, in some cases, might mean you can avoid dirtying and updating style twice thereby producing better performance. Ultimately, though, it will depend on your application since it may flush style by reading back values from getComputedStyle, innerHeight etc.

Furthermore, by using requestAnimationFrame you can ensure you only update style once per frame, even if multiple events arrive in the same frame.

Note that performance will still not match that of a regularly playing Web Animation since, unlike a regular animation, it will not be possible for the browser to offload this manually-driven animation to the compositor (which can potentially reduce battery usage because style does not need to be updated on the main thread). The forthcoming scroll-linked animations feature should help with this.

brianskold
  • 809
  • 5
  • 10
  • Awesome. Looks like you’ve got experience on the Firefox team. Just the kind of answer I was hoping for:):) – risingtiger Mar 15 '22 at 04:10
  • 1
    Thank you! I realized I didn't address the question of jank, however. By setting the `currentTime` on the main thread your animation will be prone to main thread jank. The only real solution to this for scroll/pan related animations, however, is the scroll-linked animations spec which should allow at least scroll animations to be performed off-main thread. That is actively being worked on in Firefox/Chrome and Safari seem to be onboard too. – brianskold Mar 16 '22 at 06:24