When fixing bug 204717 we made it so that we wouldn't attempt to run a CA animation if the animation's playback rate is different than 1. This bug is about trying to lift this restriction.
<rdar://problem/63182225>
Looks like we can make this work with this approach: 1. create a CAAnimation 1. set `animation.duration` to `webAnimation.duration` 2. set `animation.beginTime` to `-webAnimation.currentTime` 2. create a CAAnimationGroup 1. set `group.speed` to `webAnimation.playbackRate` 2. set `group.duration` to `webAnimation.effect.duration - webAnimation.currentTime` 3. set `group.animations` to `[animation]`
Actually, I think the solution is to set the CAAnimation timeOffset to match the Web Animation's currentTime and set speed to match playbackRate, but set the computed duration on a parent CAANimationGroup to clip.
In creating a library built upon WAAPI the only bugs I've encountered are in Webkit, and the majority of those have involved accelerated animations. These aren't bugs I can reasonably ship to users, and setting playbackRate to 1.000001 to force animations onto the main thread in Webkit has fixed them all. If this ticket gets resolved can you also offer a way to flag to Webkit that an animation shouldn't run on the main thread? Because looking through many of the tickets here, and indeed the linked bug in this one, a quick fix has often been to add conditions when an animation shouldn't run on Core Animation. It would be great if you could extend to developers this same opportunity, as I'm concerned that my hacky solution will re-expose users to timing bugs if they're not fixed before this ticket is resolved.
(In reply to Matt Perry from comment #4) > If this ticket gets resolved can you also offer a way to flag to Webkit that > an animation shouldn't run on the main thread? Apologises, that should read "should run on the main thread". Specifically something like element.animate(keyframes, { _webkitRunOnMainThread: true }) would be appreciated.
Matt, while I understand where you're coming from, I don't think offering a way to explicitly disable accelerated animations is the right approach. Rather, we need to fix bugs related to accelerated animations, so thanks for filing the bugs you have filed for now and to keep filing them as you find them.
I agree it’s not an ideal approach. In lieu of that would it be possible to consider the main-thread/accelerated synchronisation bugs in https://bugs.webkit.org/show_bug.cgi?id=229399 as a higher priority than this ticket? As it’s the only remaining blocker as of iOS 15
Agreed, bug 229399 is something I will look into soon.