6d9cc301a7
A turn is not one shape change: the viewport passes through every shape between the one it left and the one it lands in, and each of them re-letterboxes the picture somewhere else. Painted, that run of hard jumps is the stutter. So for the length of a turn the slides are held at the size they already had, and the moment the viewport stops moving they take the size it ended at -- measured, not guessed. The picture moves exactly once, straight into the position and size it then keeps. The device's own `orientationchange` starts the hold, which is the earliest anything can know a turn is coming and the one signal that separates it from a window being dragged wider; failing that, the viewport swapping its long side for its short one does. A viewport that only changes height is the browser's chrome sliding away, and is never held. Underneath: snapping is off while the slides are held, so the container cannot re-anchor on the old height at the same time; a scroll arriving during the window is put back in the event rather than a frame later, so the stale position is never painted; and the per-frame realign only writes what actually differs instead of costing a layout sixty times a second. Measured over a recorded turn: the picture moves 12 times -> 2, once per turn; the worst of those was a 660px jump between two intermediate shapes and is now the one step into the final size; the reel is never off its step (was 660px out); and the clip never pauses. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MPZFnNdHbPGDTqQUNiE4ZN
77 KiB
77 KiB