The status bar, the resolution readout and the magnifier were all regenerated
on every single mouse motion event. Each regeneration repaints, and on a remote
X session a repaint uploads the whole window regardless of how little changed,
so the pointer merely crossing the image saturates the link: measured with a
counting relay in front of the X server, 50 motions over the image cost 273 MB,
and a build with the hover work removed cost 18 KB.
Rate-limit it. Two details matter:
- The limit is applied inline, not from a timer. Running the update inside the
mouse event keeps its damage in the same repaint as anything else that event
triggers (a pan). A first attempt deferred the work to a timer instead, which
split one repaint into two and made panning measurably worse.
- The catch-up that reports the final position is debounced, not queued per
skipped motion, so it fires once after the pointer stops rather than
repeatedly mid-gesture.
mouseHover() now takes the scene position and modifiers instead of the event,
which also removes the identical mapToScene() from all four implementations.
Hover traffic over 3 repeats: 173 MB mean -> 140 MB, and the run-to-run spread
drops from +-14% to +-2%. The harness tops out near 30 motions/s, barely above
the 15 Hz limit; a real mouse reports far faster, where the cap does more.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
leonarski_fandClaude Opus 5
501ce1ba3d