Problem / Background

The current rendering pipeline still rebuilds a full-screen content string before differential output is applied. DifferentialRenderer avoids repainting unchanged lines, but the application still pays several hot-path costs first:

• building the full content buffer for the frame
• hashing the entire frame content
• splitting it into lines for diffing
• issuing repeated terminal housekeeping calls that could be reduced
• allocating many short-lived strings in process/table rendering paths

After #135, #136, and #137, these rendering-path microcosts become the next major target.

Proposed Solution

Refine the render engine so it does less work before reaching the differential update stage, and trim avoidable terminal/syscall/allocation overhead in the hottest paths.

Scope

Rendering pipeline refinement

• Evaluate replacing the monolithic full-screen string path with a more line-oriented or section-oriented frame representation
• Reduce the amount of work needed before unchanged lines can be skipped
• Keep differential rendering behavior correct across resize and mode transitions

Terminal housekeeping reductions

• Avoid redundant terminal size queries in nested rendering paths
• Avoid per-frame cursor hide/show churn when session-level cursor state is sufficient
• Review flush / clear behavior to ensure it is only done when necessary

Hot-path allocation cleanup

• Reduce repeated short-lived String allocations in process table and related renderers
• Reuse buffers where practical in line/row formatting paths
• Keep formatting logic readable while trimming obvious hot-path waste

Measurement support

• Add lightweight profiling or benchmark coverage for the render path where practical
• Compare before/after cost for idle frames, large process lists, and large remote views

Acceptance Criteria

• The render path performs less pre-diff work than the current full-screen string pipeline
• Redundant terminal size / cursor / flush operations are reduced without breaking display correctness
• Process table and other hot renderers allocate less temporary data per frame
• Resize handling and differential updates remain visually correct
• CPU usage drops further in large or long-running sessions compared with the post-Cache derived TUI view data to avoid per-frame sorting, filtering, and cloning #137 baseline

Integration and Verification Requirements

• The implementation must be verified by actually running the affected code path and confirming the intended behavior works end-to-end
• Verification must cover both behavior correctness and the expected performance/responsiveness improvement for this issue
• The final result must be integrated into the existing project flow, not left behind as an isolated module, helper, or function that is not exercised by the real application path
• Completion is not satisfied by adding code alone; the change must be wired into the real local/remote TUI execution path and confirmed to be active in practice

Technical Considerations

• The goal is not to prematurely micro-optimize everything, but to remove repeated hot-path work that remains after the larger architectural changes land.
• This should be treated as the fourth implementation step, after Reduce TUI idle CPU and improve responsiveness with event-driven UI wakeups #135, Snapshot AppState before rendering to shorten the TUI critical section #136, and Cache derived TUI view data to avoid per-frame sorting, filtering, and cloning #137.
• Any line-oriented/frame-structure redesign should preserve the maintainability of the TUI codebase.