Release 0.2.3

0.2.3 (2026-07-29)

Bug Fixes

• anchor the Android animation clock to the choreographer frame axis (1218806)

Features

• explicit-start animateTo via animation.from (70049a7)

An interactive drag hands off to animateTo mid-frame: the animation start
was stamped on steady_clock at the call, but the choreographer ticks the
integrator against frameTimeNanos — a vsync stamp that precedes the call.
The first fraction clamped to zero and re-rendered the start, a 1–2 frame
freeze whose visible size scales with drag velocity (invisible on a slow
drag, a 30–100 px freeze-then-jump on a fast one). The first advance()
now translates the start onto the frame-time axis preserving real elapsed
time: the first rendered frame advances honestly and later frames pace on
vsync. iOS was never affected (the render server interpolates committed
CAAnimations) and is bit-identical to 0.2.2.

animation.from packages the release handoff as a first-class option on
all three animation kinds: a fused take-ownership hot write issued
immediately before the animation, so the rendered value, the native start,
and keyframe 0 are identical by construction — replacing the two-call
setScalars(...) + animateTo(...) pattern apps had to discover, and
also re-grabbing from a running animation, which the implicit interactive
start silently skipped. Wire format unchanged; no native code touched.

See docs/android-frame-clock-anchor.md for the full defect analysis and
the architecture verdict.