Bugzilla

Once after bug 1626165 landed, we use the last composited value on the compositor for newly created transitions as the start value if the transition replaces an old transition, but still we keep using a stale start value on the main-thread, it results jumpy animations when the throttled transitions flushed on the main-thead.

The jumpy animations will be mitigated by bug 1632957 if the flush is caused by event handling stuff.  But bug 1632957 doesn't help cases where the flush is caused by other reasons.  So ideally we should also update the start value on the main-thread as well as on the compositor.

I wrote a hacky patch to do that.  As of now it just works only for transform property with WebRender.  On my environment, it's quite hard to notice the original jittery transition so i't hard to tell whether the patch will fix the jumpy animations or not.  But hopefully it will solve it without bug 1632957 (theoretically, the patch should fix the issue without bug 1632957).

Once after bug 1626165 landed, we use the last composited value on the compositor for newly created transitions as the start value if the transition replaced an old transition, but still we keep using a stale start value on the main-thread, it results jumpy animations when the throttled transitions flushed on the main-thead.

The jumpy animations will be mitigated by bug 1632957 if the flush is caused by event handling stuff.  But bug 1632957 doesn't help cases where the flush is caused by other reasons.  So ideally we should also update the start value on the main-thread as well as on the compositor.

I wrote a hacky patch to do that.  As of now it just works only for transform property with WebRender.  On my environment, it's quite hard to notice the original jittery transition so i't hard to tell whether the patch will fix the jumpy animations or not.  But hopefully it will solve it without bug 1632957 (theoretically, the patch should fix the issue without bug 1632957).

Once after bug 1626165 landed, we use the last composited value on the compositor for newly created transitions as the start value if the transition replaced an old transition, but still we keep using a stale start value on the main-thread, it results jumpy animations when the throttled transitions fare lushed on the main-thead.

The jumpy animations will be mitigated by bug 1632957 if the flush is caused by event handling stuff.  But bug 1632957 doesn't help cases where the flush is caused by other reasons.  So ideally we should also update the start value on the main-thread as well as on the compositor.

I wrote a hacky patch to do that.  As of now it just works only for transform property with WebRender.  On my environment, it's quite hard to notice the original jittery transition so i't hard to tell whether the patch will fix the jumpy animations or not.  But hopefully it will solve it without bug 1632957 (theoretically, the patch should fix the issue without bug 1632957).

Once after bug 1626165 landed, we use the last composited value on the compositor for newly created transitions as the start value if the transition replaced an old transition, but still we keep using a stale start value on the main-thread, it results jumpy animations when the throttled transitions are flushed on the main-thead.

The jumpy animations will be mitigated by bug 1632957 if the flush is caused by event handling stuff.  But bug 1632957 doesn't help cases where the flush is caused by other reasons.  So ideally we should also update the start value on the main-thread as well as on the compositor.

I wrote a hacky patch to do that.  As of now it just works only for transform property with WebRender.  On my environment, it's quite hard to notice the original jittery transition so i't hard to tell whether the patch will fix the jumpy animations or not.  But hopefully it will solve it without bug 1632957 (theoretically, the patch should fix the issue without bug 1632957).