R360 motion that eases: a ring click that speeds up and slows down, a drag that coasts, the owner's switch

[Devski]

Wanted by Dawid on 11.09.2026, for later — outside the R360 milestone.

Today

In src/components/ui/use-orbit.ts:

• A click on the ring travels at a constant pace — 28 ms a frame, 250–1200 ms in all — starting and stopping at full speed.
• A drag on the picture follows the hand frame by frame and stops dead the moment the hand lets go.

Wanted

• Ease in and out on a travel: a ring click (and a cue click, R360 cue points: labelled frames on the ring, shown on hover, reached by a click #107) speeds up, then slows into its frame.
• A drag that coasts: after release the orbit keeps turning at the hand's speed and slows to a stop.
• The owner's switch, per work: on or off, among the R360 parameters of the edit form. Stored in works.r360_params (JSON) as an optional field, so no migration. Which way a work saved before it reads — on or off — is to be decided.
• prefers-reduced-motion keeps winning: no easing and no coasting, whatever the owner chose.

To tune on a phone with Dawid: the curve, how long a coast lasts, and whether a slow release coasts at all.

Spec: SPEC.md A13 · Related: #106, #107

[Devski]

Follow-up filed as #175, from Dawid on 12.09.2026 — it builds on this rather than changing it, so it belongs after PR #171 lands, not inside it:

• the motion switch becomes parameters, with ease-in and ease-out set separately per work (still r360_params, still no migration);
• every travel eases, whichever of the three places started it — the ring, a ring marker, or a cue button — with a test that says so;
• and the cue row: a button lights on the press rather than on the arrival, the cursor over it is a pointer (Tailwind 4 no longer sets that on button, and the shared base class does not either), and an orbit passing a cue may pulse but must not blink — within the contrast constraint this row's comment already records.

[Devski]

Done 12.09.2026, #171, squashed as 3ab5f69.

• A travel eases. It gathers pace, runs fastest halfway and settles onto its frame — a ring
  click, and a cue point (R360 cue points: labelled frames on the ring, shown on hover, reached by a click #107) with it.
• A drag coasts. Thrown rather than put down, the orbit keeps turning at the hand's speed and
  slows to a stop.
• The owner's switch, a sixth parameter beside the direction, in works.r360_params — no
  migration.
• Reduced motion still wins, whatever the owner chose.

The open question, decided: a work saved before the switch existed glides. The field is
stored the other way about from the cue points — absent means ON, and only an owner turning it off
is ever written down. Nothing to backfill, and isDefaultR360Params still reads untouched
parameters as untouched. The motion is a quality every orbit should have had, not content the owner
has to author; shipping it off would have meant almost nobody ever saw it.

Not done, deliberately: dragging the marker round the ring does not coast. That gesture is a
slider — you put the marker down where you want it — not a throw.

How it is built

The coast is not a second mechanism. coastAfterDrag reads the speed of the throw, works out how
far constant slowing carries it and how long that takes, and hands those frames to the same travel
a ring click uses. A grab, a key, a frame count that changed under the hook and the #161 landing
timer hold a coast exactly as they hold a travel, with none of them taught anything new. Its curve
is not chosen by eye either: 2t − t² IS where constant slowing puts a thing, the same motion the
distance was measured with, so the frames and the time cannot drift apart.

What review caught, and it was the important one

The speed was measured between pointer moves, so the time a hand spends resting before it lifts
never reached the divisor. The measured speed stayed exactly what it had been while the hand was
still travelling — right up to the moment the sample window emptied, and then fell to nothing. A
finger lifts tens of milliseconds after it stops, which is the ordinary gesture, so "drag, stop,
let go" would have thrown the orbit most of the way round. Simulated on a 72-frame set: 51 frames
of coast after a 60 ms rest, where it should have been 6.

The lift is now a reading like any other rather than merely the moment of asking: resting lengthens
the span without lengthening the distance, and the throw drains smoothly to nothing.

Two smaller ones from the same pass. The press is no longer recorded as a reading — it is where the
finger landed, not motion, and counting it measured a speed across the drag slop, so a tap that
wobbled 8 px could throw the orbit. And the readings are stamped with event.timeStamp rather than
performance.now(): on an orbit page the main thread stalls decoding frames, the queued moves then
drain in one task, and handler time would read a whole swipe as having happened at once.

Two existing e2e drags had to be fixed first

dragAcross in e2e/db/r360.spec.ts and the preview drag in e2e/db/works.spec.ts do
mouse.down → mouse.move(…, {steps: 4}) → mouse.up with no pause. Playwright lands those moves
within a millisecond of one another — a speed no hand reaches — so every one of them became a
maximal throw. The works-form one would have failed outright: "Użyj tej klatki" reads the frame in
view mid-spin, and that test ends on an exact toEqual of the POST body. Both now come to rest
before letting go, which is what they always meant by a drag; dragAcross takes { thrown: true }
for the one case that wants a throw.

Tuning

The feel is one constant, COAST_SLOWING in src/lib/r360/orbit.ts — it sets how fast a coast
sheds speed, and so both how long a throw runs and how far it carries. Smaller is longer and
further. The tests assert properties rather than numbers, so turning it cannot break them. It
stands at its shipped value for now; the phone session with Dawid can still move it.

Known, and left alone

With two fingers on one picture the second overwrites the first's anchor, so lifting the first can
start a coast measured from the second's readings. That is in use-orbit.ts since #103 and
touch-action: pan-y usually has the browser cancel the pointers first; fixing it is a change to
the drag gesture itself, outside this issue.