Redraw on every key press in the interactive viewer - #96
Merged
Conversation
Key presses were dispatched through the drag throttle, so a press within 30 ms of the previous draw mutated the view or style but dropped the redraw with nothing scheduled to catch up. A key press is a discrete action with no follow-up event, so it now always redraws; the throttle is reserved for drag motion, where release guarantees a final draw.
bjmorgan
force-pushed
the
fix-key-redraw-throttle
branch
from
September 1, 2026 20:18
f06d60d to
2c2c81a
Compare
Style toggles are now view redraws, so the _full_redraw docstring and the _apply_key_action return-kind docstring described a split that no longer exists; state the rule instead. Reword the key-press comment to cover auto-repeat, and return "none" for keys swallowed during number input, which change nothing and previously triggered a wasted repaint.
The test relied on both presses arriving within the throttle window by wall-clock luck, so on a slow runner a re-throttled key handler would still draw and the test would pass. Stub the module's time source so every press is inside the window and a throttled redraw is always dropped.
There was a problem hiding this comment.
🟢 Approval recommended
The change is narrowly scoped, matches the described bug, and is backed by a deterministic regression test covering the previously dropped-redraw scenario.
Review details
- Files reviewed: 3/3 changed files
- Comments generated: 0 new
- Review effort level: Lite
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Stacked on #95.
Key presses in the interactive viewer were dispatched through the same 30 ms throttle as drag motion. A press made within that window of the previous draw (straight after releasing a drag, or two toggles in quick succession) mutated the view or style but dropped the redraw, and nothing was scheduled to catch up, so the display stayed stale until the next interaction.
A key press is a discrete action with no follow-up event, so it now always redraws. The throttle is reserved for drag motion, where the release handler guarantees a final draw. Style toggles need only a repaint rather than a full recompute: precompute never reads the toggled flags, the painter gates on them at draw time.
Also tidies the
_apply_key_actiondocstring so "view" and "full" describe what the kinds actually mean, and drops a comment in the fidelity test that explained why the throttle happened not to bite there.