连续设置 Web Animation API 的 currentTime 属性对性能/效率有何影响？
在毫秒内连续更新 Web 动画的 currentTime 属性对性能/效率有何影响？
我想做的是将网络动画在其时间范围内的当前点与用户在屏幕上平移手指联系起来。通常，这是通过从指针移动事件调用 requestAnimationFrame 并直接在元素上设置 css 属性来完成的。但是，我想使用网络动画。
let animatedObj = animatedEl.animate(props, timing)
animatedObj.pause()
el.addEventListener('pointermove', (event) => {
animatedObj.currentTime = (.... percentage of pointer position ....)
})
但它是否比 requestAnimationFrame 和直接设置 css 属性更容易出现卡顿或电池能耗？设置currentTime不是为了在ms内持续更新而设计的吗？在设置动画的 currentTime 的同时使用 requestAnimationFrame 会更好吗？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
以这种方式设置 currentTime 是完全可以接受的，理论上应该比直接设置 CSS 属性性能更高，因为不需要在每个帧上重新解析 CSS 属性值。但实际上，差异应该可以忽略不计。通过使用网页动画，您还可以利用缓动效果等，这可能是一个优势。
我假设您的示例中的
animatedObj已暂停。通过暂停它，您可以确保当平移位置没有改变时，它不会不必要地触发样式更新。通过使用 requestAnimationFrame ，您可以确保回调在样式更新之前运行（但在动画时间更新之后），在某些情况下，这可能意味着您可以避免两次弄脏和更新样式，从而产生更好的结果表现。但最终，这将取决于您的应用程序，因为它可能会通过从
getCompulatedStyle、innerHeight等读回值来刷新样式。此外，通过使用
requestAnimationFrame您可以确保每帧只更新一次样式，即使多个事件到达同一帧也是如此。请注意，性能仍然无法与定期播放的 Web 动画相匹配，因为与常规动画不同，浏览器无法将此手动驱动的动画卸载到合成器（这可能会减少电池使用量，因为样式不会需要在主线程上更新）。即将推出的滚动链接动画功能应该会对此有所帮助。
It's quite acceptable to set the
currentTimein 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
animatedObjin 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
requestAnimationFrameyou 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 fromgetComputedStyle,innerHeightetc.Furthermore, by using
requestAnimationFrameyou 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.