Frame

A press that lands mid flight and a hand that lets go mid flight ask the runtime for the same thing: start a new spring from wherever the component is, at whatever speed it has. So the hand needed no physics of its own. While it holds on, every channel follows its progress between the two measured layouts, and where one part leaves as another arrives the first fades out before the second fades in. When it lets go, the speed is the slope of its last 80 ms of pointer samples, and the ordinary interruption code takes over from there.

Nothing in between is eased or guessed, which is why a hard throw overshoots and a slow one does not. What is yours to decide is the rule. Below is one press and the press that undoes it, under each of the three rules Frame can export. Move the second press and all three are worked out again.

A plate is a long exposure of a take. The shutter opens at the first event and closes when the motion rests, and the moving target leaves its outline wherever it is, so ink builds up where it lingers. A turning point prints as a dark line, a slow settle as a dense band, and a snap leaves almost nothing. A flash at 60 Hz adds one crisp outline for each display frame.

The lines are moments worked out from the take, they are not measured paints. Save plate gives you the print as an image, with the trace beside it at the same scale, so a dark line on the plate sits level with the turn in the curve that made it. Copy link gives an address that holds the take itself, every pointer sample of it, and replays it.

Tune also writes the opening spring as a CSS linear() easing, for when a stylesheet is all you want. From rest it follows the spring within 0.2% of the distance, which for the expense card is under half a pixel. A unit test reads the written string back and checks that bound for 13 springs at 3 distances.

What an easing cannot hold is a speed. A CSS transition that is reversed starts its easing again from rest, so the edge stops dead and sets off again. The runtime carries the speed through the turn. The right half of the figure works both out for the reversal above. It is computed here from the CSS rule for a reversed transition, and no browser run compares the two.

The studio preview and the exported app are two builds of the same evaluator, so comparing them says nothing about the physics. It tests everything around the physics: the build, the CSS and the replay path. Across 120 scripted runs in Chromium, WebKit and Firefox the two drew within 0.000023 px of each other, against a 0.5 px target.

Whether the springs are right is a separate question with a separate answer. Real browser geometry was read against an independent RK4 solution that shares no code with the runtime. The worst case was 0.094 px, against a 0.11 px target, and most of that is the 0.1 px snap when a spring settles.

A check that cannot fail proves nothing, so 9 faults were written into clean builds, from a dropped velocity to damping set 2 percent high. All 9 were caught, and neither of the 2 clean builds was flagged. The first full run caught 8 of 9, so it was thrown out, the fixture was changed so the missing fault could show, and everything was measured again.