[Webkit-unassigned] [Bug 229399] Composited & non-composited animation iterations are unsynced

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=229399

--- Comment #8 from Antoine Quint <graouts at webkit.org> ---
I don't have good news to report about this bug.

While I have fixed the egregious issue with the animation for one of the sqaure not animating in the same way as the other squares with bug 229398, the cruz of the issue with the "background-color" and "transform" animations not iterating in sync is something that I don't believe we can fix with our current architecture.

When we run the "transform" animation in this case, we delegate the actual animation to Core Animation. This has some important benefits: animations run smoothly regardless of any potential delays on the main thread (think JS work or delayed rendering due to large CSS or DOM changes), are very power-efficient, and on Apple hardware with Pro Motion displays, those animations can run at a higher frame rate than those run in software.

Meanwhile, the "background-color" property animation is not delegated to Core Animation. Instead we animate this property much like we animate the bulk of CSS properties in WebKit: while the animation is "relevant" per Web Animations terminology, we schedule page rendering updates and invalidate styles for the target element such that we can animate the CSS value. The frame rate typically obtained for these types of animations is 60fps.

There are two potential synchronization issues with this approach when mixing software and "accelerated" (delegated to Core Animation) animations.

The first one, which is the crux of this bug, is that while we ensure that both kinds of animations use the same start time and are mapped correctly to the respective time origin of the worlds in which those animations live, the problem is that those animations are _not_ resolved in a coordinated manner. So while Core Animation and WebKit itself may sample animations at 60fps, within a given frame, the animations may resolve at a different iteration progress because the time within the 1/60 second that the frame may last that they are sampled is going to be different. The difference is likely a few milliseconds and for a lot of animations, this will not prove to be a problem.

However, in this case, you have those two animations running with the same timing, so when we reach the end of an iteration, one animation may be ever so-close to an iteration progress of 1, while the other animation maybe instead a hair above an iteration progress of 0.

The second potential synchronization issue is really just a different version of this first issue when, on a Pro Motion display for instance, the software and accelerated animations may run at a different frame rate, Core Animation being able to sample animations at 120fps while the software animations would still run at 60fps.

This means that while we may be off by a frame on more traditional displays, we now have the risk of being off by two frames by virtue of Core Animation sampling animations twice as fast.

There are things we could do to mitigate these issues. We could for instance try to "predict" the interval between the times where both types of animations are sampled and try to make up for this, but this wouldn't be fool-proof. I'd have to invest more time in trying to come up with a solution similar to this, but I'm not able to commit to this at the moment and cannot suggest a time when I could do this.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20220205/286fcb3e/attachment-0001.htm>