7033288bc4686f6b71300d6c651a3e7d3f8e1ed8
The slides are held at the size a turn is heading for so the picture steps once, straight into the shape it keeps, instead of being re-letterboxed through every shape the viewport passes on its way round. The hold came off once the height had gone six frames unchanged, which stood in for "the viewport has stopped moving". It does not: a turn arrives in steps, and the gap between two of them is routinely longer than six frames -- on a phone and in a loaded tab alike. So the pin came off mid-turn, the slides took an intermediate shape, and the picture jumped twice on the way round. That is the stutter the pin exists to remove, and TURN_HOLD_FRAMES was meant to be "long enough that a viewport animating round in steps is not mistaken for one that has arrived" -- six frames is not. The device does say when a turn is underway, so believe it: while the announcement stands the pin holds, and the frame count is left to end the pins nothing announced, where there is no signal to go on and no turn to ruin. The realign window has to stop concluding mid-turn too, since closing it releases the pin by the other door; SETTLE_MAX_MS outlasts the announcement and still guarantees both of them end. The cost is that an announced turn keeps the old size until the announcement lapses rather than letting go the moment the viewport looks still. That buys the one step. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MPZFnNdHbPGDTqQUNiE4ZN
Description
A webclient for hottub
Languages
JavaScript
60%
Python
29.7%
CSS
8.3%
HTML
1.7%
Shell
0.3%