[Bug] High CPU TUI usage

[RomanMIzulin]

Affected area

TUI

What happened?

Prime Agent's fullscreen TUI burns a large share of one CPU core while the agent is working, even though nothing is visibly being redrawn. It becomes dramatically worse when spawning multiple subagents. On a session with a long transcript the prime-agent process attached to the terminal sits at ~30–70% of a core while the agent streams, and only returns to 0% once the agent's turn fully ends.

Root cause: in fullscreen mode every requestRender() recomputes the whole frame from scratch — it re-renders every scroll component (header + entire transcript + widgets), composes the viewport frame, and normalizes every line — before paint() row-diffs to decide what actually changed. That recompute is O(transcript length) per frame, and it is driven at up to 60fps by the 16ms render throttle plus the 80ms working spinner (12.5 fps even when only the spinner character changes).

Steps to reproduce

1. Run ./prime-agent.sh from the repo root.
2. Open a session and accumulate a long transcript (stream a task with a lot of tool output).
3. While the agent is working, sample the TUI process CPU:
   ps -o pid,pcpu,comm -p <tui-pid> (the prime-agent process whose stdin is the terminal), or read /proc/<pid>/stat.
4. Compare CPU while streaming vs after the turn ends.

Measured on some session:

• agent streaming: ~58–70% of one core (peaks 76–80%)
• transition after turn end: ~16% → 3% → 1.8%
• fully idle: 0.0% for 117s straight

Expected behavior

The TUI should be near-idle when the screen is not changing, and render cost should be bounded by what actually changed rather than by transcript length. Maybe we should add some configuration for users who are ok with slower render in exchange for effecient CPU usage especially working with team of agents.

Prime Agent version

0.7.2

Environment

arch, ghostty

Additional context

Potential fix. Tested locally. Feel free to use as reference:
RomanMIzulin#1

• coalesces fullscreen repaints to 50ms (20fps cap) instead of 16ms (60fps), and
• slows the working spinner from 80ms to 200ms.

Headless benchmark (800-line transcript, requestRender() every 5ms for 3s):

• before: 64.3 full-frame recomputes/s
• after: 20.3 full-frame recomputes/s

That is ~3.2× fewer full-frame recomputes under identical load; render CPU scales with recompute count. Note this bounds the recompute rate, but true incremental rendering (re-render only changed rows) is still a larger follow-up.