| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
An in-flight tool box taller than the viewport (top scrolled off-screen)
flickered violently the whole time it was active. Cause: the working spinner
(and pi's default spinner) drive ui.requestRender() at ~10-16fps, and the
active call slot recomputed a wall-clock pulse color every render, recoloring
the TOP border. tui.js falls back to a full-screen redraw when the first
changed line is above the viewport (firstChanged < prevViewportTop), so every
spinner tick = one full clear+repaint.
Fix: once the result slot is streaming (box can be tall), freeze the call
slot pulse color, caching built lines per (width, inner). The header/command
is static, so the top border is byte-identical between render ticks and never
triggers an above-viewport change. The pre-output phase (box still fully
visible) keeps the live pulse + ticking runtime; the result slot still pulses
its in-viewport bottom border. NOTES.md documents this as flicker #4.
Confirmed by repro: massive flicker with the fix reverted, calm with it in.
|
| |
|
|
|
|
|
|
|
| |
Bring back body side rails with an active/settled distinction:
- in-flight: gray dotted (┊) rails + pulsing top/bottom borders
- finalized: solid status-colored (│) rails + solid borders
Rails are a STATIC per-render color (never carry the pulse), so streaming
output can't recolor existing body lines -> stays flicker-safe.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
flicker)
Third flicker bug: a taller-than-screen bash box flickered because the 10fps
timer forced a full updateDisplay() repaint on top of the stream's own
re-renders. Root fix: NEVER force a repaint.
- Pulse color is now a pure function of wall-clock time (Date.now() % CYCLE_MS);
no tick counter, no setInterval. Any render shows the current color.
- The pulse advances only on renders that already happen: streaming output
('the stream hydrates the pulse', irregular cadence) or start/end nudges.
- Silent long-running tools hold a static active color (flicker-free) rather
than animating.
- Also drop body side rails entirely (open-sided box); only top/bottom pulse.
Self-test: restored rows never pulse, active top border advances with time,
settles solid on end.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Two bugs from the pending-tool border pulse:
1. Streaming flicker: pulsing the side rails recolored every body line each
frame, forcing a full-box repaint per streamed token. Now only top/bottom
borders pulse; rails/body use a static status color.
2. Startup render storm (pi -c never accepts input): 'pending' was inferred
from the render-time default status, so every RESTORED tool row rendered as
pending -> all added to the 10fps animation set -> unbounded invalidate loop.
Animation is now driven strictly by live tool_execution_start/end events
keyed by toolCallId; restored rows fire no start event so they never animate.
Self-test covers: restored rows don't pulse, live rows pulse only between
start/end, rails static during a run.
|
|
|
Record the redraw-flicker-during-write report as a tracked safety issue.
Prime suspect: the 10fps pending-tool border pulse (slop-tool-boxes d3454b8)
driving full-frame repaints ~10Hz (photosensitive-seizure risk band).
|
