Defer animation start time in FrameAnimationDriver

[zeyap]

Summary:

Changelog:

[Internal] [Fixed] - Defer animation start time in FrameAnimationDriver

Problem: In complex apps, if animation is started in commit phase (the case if animation starts in useLayoutEffect, or from ViewTransition event handlers), it'll skip initial frames — the user sees the animation snap to an intermediate position. This happens because FrameAnimationDriver anchors its start time on the first runAnimationStep call, but the UI thread may be busy with layout/mount work for several frames before the view actually composites. The elapsed wall-clock time advances, causing frameIndex to jump ahead.

Why: startFrameTimeMs_ is set to the Choreographer frame time on the first tick. If the UI thread is blocked processing a heavy tree (many views mounting), subsequent ticks arrive much later — timeDeltaMs jumps and the animation skips to a mid-point.

• Every major framework solves this: Flutter uses lazy start (_startTime ??= timeStamp on first actual tick), Android native uses CALLBACK_COMMIT to adjust post-traversal, and CSS View Transitions spec defers start until post-composite.

Fix: On the very first update() call, output the starting value (frame 0) and reset startFrameTimeMs_ = -1. This causes the base class to re-anchor on the next runAnimationStep, so elapsed time is measured from the first frame that has actually been rendered — not from when startAnimatingNode was dispatched. The flag disables itself after one use, so all subsequent frames use pure elapsed-time with no behavioral change.

Differential Revision: D106007152

[meta-codesync]

@zeyap has exported this pull request. If you are a Meta employee, you can view the originating Diff in D106007152.