Static (non-dirty) elements vanish from screen after the first redraw because full-screen Clear() runs every frame

[matt-edmondson]

What's wrong

UIApplication.Render() unconditionally calls ConsoleProvider.Clear() (wiping the entire terminal buffer) on every render pass, but UIElementBase.Render() only actually draws content when IsDirty is true:

if (IsDirty) { OnRender(provider); IsDirty = false; }

IsDirty is reset to false immediately after an element's first draw. ProcessInputAsync calls Render() again after every processed input, regardless of which element(s) the input affected.

These two mechanisms fight each other: the screen is fully cleared every frame, but only elements still flagged dirty get redrawn. Any element that isn't re-marked dirty by the input that just happened disappears from the screen on the very next frame.

Failure scenario

Build any app with a BorderElement wrapping static TextElements plus one interactive child (e.g. a text input). Press any key that the interactive child handles but that doesn't invalidate the border/label. On the next render pass: the terminal is cleared, the interactive child (still dirty) redraws, but the border and static text (no longer dirty) are skipped — they vanish. This reproduces on the very first keystroke in the most ordinary layout (a label next to a focused control).

Suggested fix

Pick one rendering model instead of combining both:

• Drop the per-Render() ConsoleProvider.Clear() and rely purely on dirty-region drawing (write only changed regions, no full clear), or
• Drop the dirty-check gate for the full-clear model and always call OnRender on every pass so the whole tree redraws after each clear.

Acceptance criteria

A layout with static and interactive elements retains all static content on screen across multiple render passes triggered by unrelated input.

[matt-edmondson]

Triage

Category: Bug (core rendering model)
Priority: Critical
Area: TUI.Core — UIApplication.Render(), UIElementBase.Render()

Highest-severity item open in this repository. Two rendering models are combined in a way that cancels out: the screen is fully cleared every pass, but only elements still flagged IsDirty are redrawn — and IsDirty is cleared after the first draw. Any static element therefore disappears on the next frame. The issue is right that this reproduces on the very first keystroke in the most ordinary possible layout (a label beside a focused input), which means the library does not currently work for its primary use case.

Critical rather than High because this is not a defect at the edges — it is the central render loop, and no consumer can build anything real until it is resolved.

Related: #110 and #111 in this repo are also in UIApplication's loop and lifecycle (RunAsync teardown, Render sizing). Different root causes, but whoever picks this up will be in the same file, and the resize fix in #111 depends on which rendering model is chosen here — so fix this one first and let #111 follow.

Not covered by an open PR.

Suggested next step: this needs a deliberate decision rather than a patch — pick one of the two models in the issue and commit to it. Full-clear-plus-full-redraw is the simpler and more obviously correct starting point; dirty-region drawing is the better end state but needs the clear removed and real region tracking, which is a larger piece of work.

---

Generated by Claude Code