Scrubbing a number in the inspector and dragging a colour stop of a
gradient told the editor about every input. Pixi repeats each pointer
move shortly after, so both gestures paid for two previews per move.
The issue asked to measure first and to build only from 10 % per
move. The measurement showed about 50 %.
- previewingHandlers still writes the model on every input but
requests the preview through a FramePreview of its own. The commit
cancels a waiting preview first.
- The preview handler of the GradientBar in shapeSection.ts does the
same.
- Wider than the issue describes: the row handlers also serve typing,
the arrow keys and the colour picker. All of them preview once per
frame now.
Measured on stein2, fixture project with 120 extra objects, 120 moves
8 ms apart, three runs each:
- Scrub: 236 project events before, 51 to 61 after. 45 to 50 ms per
move before, 22 to 27 after.
- Colour stop: 238 project events before, 50 to 51 after. 44 to 49 ms
per move before, 22 after.
- One preview still costs 13 to 17 ms. That price per frame is what
remains.
Finding, not fixed here: in the pixel art tab the palette colour and
the opacity of a layer still preview on every input
(PixelArtSide.ts), and so do the head fields of the curve tab.
Neither was measured.
Tests:
- Gate: 198 files, 2907 tests (2903 + 4), exit 0
- e2e, full run: 1616 checks passed (1615 + 1), exit 0
- Smokes: 24 / 19 / 21, exit 0
- Four new unit tests in tests/editor/frame-preview.test.ts, two for
a row and two for a colour stop
- One new e2e check in module 02: a held scrub gave 10 project events
in 12 frames, and the value is there before the release
- Four unit counter-probes fail, 1 to 2 tests each. They ran on
stein2, not in the container.
- The browser counter-probe fails the new check with 50 events in 16
frames
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
adminandClaude Opus 5.5
c4a9280140