Basically we [align the start time with mPendingReadyTime](https://searchfox.org/mozilla-central/rev/3bf363d4d4ff97cfccb8f378e7b1d32a09dc1580/gfx/layers/AnimationInfo.cpp#86-108). So when we send the transition info to the compositor, the animation has run for a while if the main thread is busy, and so the "start time"/"ready time" is behind the current time a little bit (and it is noticeable). Therefore, this may cause the transition jump a little bit, even if we recompute the start value or set start value by the last value on the compositor. I guess the gap between ready time and real start time on the compositor become huge since we removed the PendingAnimationTracker (especially for busy main thread), and so we may still need more tweak on it. However, I have no idea for now.
Bug 1901641 Comment 3 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Basically we [align the start time with mPendingReadyTime](https://searchfox.org/mozilla-central/rev/3bf363d4d4ff97cfccb8f378e7b1d32a09dc1580/gfx/layers/AnimationInfo.cpp#86-108). So when we send the transition info to the compositor, the animation has run for a while if the main thread is busy, and so the "start time"/"ready time" is behind the current time a little bit (and it is noticeable). Therefore, this may cause the transition jump a little bit, even if we recompute the start value or set start value by the last value on the compositor. I guess the gap between ready time and real start time on the compositor becomes huge since we removed the PendingAnimationTracker (especially for busy main thread), and so we may still need more tweak on it. However, I have no idea for now.