Fixes #5499. Skip SetNeedsLayout when Dim.Auto text recompute yields unchanged size

[harder]

Fixes #5499.

Problem

The View.Text setter unconditionally called SetNeedsLayout(). That marks the view and its whole subtree as needing layout, sets _needsDrawAfterLayout, and propagates up the entire ancestor chain on every text change, even when the recomputed frame is identical to the current one (e.g. a once-per-second clock Label).

The layout machinery already no-ops the frame mutation when nothing changed (SetRelativeLayout only calls SetFrame when Frame != newFrame), but the layout pass, formatter setup, redraw scheduling, and ancestor invalidation were still being scheduled every tick.

Change

Terminal.Gui/ViewBase/View.Layout.cs

Extracted SetRelativeLayout's Pos/Dim -> absolute-Frame resolution into a private TryComputeRelativeFrame (Size, out Rectangle). SetRelativeLayout now calls it, and so does the Text setter's speculative check. This keeps frame prediction and real layout on the same computation path.

Also extracted SetRelativeLayout's post-frame TextFormatter constraint cleanup into FinalizeTextFormatterConstraints(). This matters because UpdateTextFormatterText() clears ConstrainToWidth/ConstrainToHeight; if the text setter skips layout, the fast path must still restore the same formatter constraints a full layout pass would produce so wrapped/clipped text formats correctly.

Terminal.Gui/ViewBase/View.Text.cs

The setter now calls TryRedrawWithoutLayout() after updating TextFormatter.Text.

When the view has already been laid out and both Width and Height are eligible, TryRedrawWithoutLayout() resolves the would-be Frame via TryComputeRelativeFrame. If the predicted frame equals the current Frame, it skips SetNeedsLayout() and ancestor propagation, then:

• finalizes TextFormatter constraints with FinalizeTextFormatterConstraints();
• sets TextFormatter.NeedsFormat = true;
• calls SetNeedsDraw();
• lets the setter raise TextChanged normally.

The comparison is the full Rectangle (position and size), not just dimensions. A Pos can depend on Text (e.g. Pos.Func reading view.Text), so a same-size text change can still move the view and must run layout.

Eligibility is exact by design:

static bool IsEagerlyResolvable (Dim dim) => dim is DimAbsolute or DimAuto { Style: DimAutoStyle.Text };

• DimAbsolute is constant; a Text-only DimAuto depends on this view's TextFormatter.
• DimAutoStyle.Content / DimAutoStyle.Auto can lay out subviews while calculating, so those fall back to SetNeedsLayout().
• Composite/nested dims such as Dim.Auto(Text) + 2 are not bare DimAbsolute/DimAuto, so they also fall back.

This covers the intended safe cases: both-axis Text-auto, fixed-size text redraws, and one-axis-auto (Width = Auto(Text), Height = 1). The optimization only avoids setting NeedsLayout; it never clears a pre-existing pending layout request.

Tests

Added focused layout and render coverage:

• Tests/UnitTestsParallelizable/ViewBase/Layout/Dim.AutoTests.TextOptimization.cs

  • ancestor diagnostic: same-size text change leaves superView.NeedsLayout == false while the view still redraws;
  • full-frame guard: Pos.Func depending on Text forces layout when same-size text moves the view;
  • exact guard: composite dims bypass the fast path;
  • fixed-size and one-axis-auto fast paths;
  • formatter constraint survival for fixed-size and one-axis-auto word-wrap cases;
  • clock-style repeated same-width updates with no frame drift or ancestor propagation;
  • reentrant TextChanged handling;
  • min/max, border adornment, uninitialized, DimAutoStyle.Auto, different-size, and pending-layout cases.

• Tests/UnitTestsParallelizable/ViewBase/Layout/TextFastPathRenderTests.cs

  • compares the isolated redraw-only fast path against a forced full-layout control;
  • verifies rendered driver contents match for fixed-size wrap, fixed-size clip, single-row clipping, and max-constrained Text-auto wrapping.

Additional exploratory probes were run and removed after conversion of the high-value cases into permanent tests. They compared fast-path vs full-layout behavior across repeated text updates, fixed/min/max/Text-auto dimensions, word-wrap on/off, explicit content-size constraints, Button, CheckBox, and reentrant handlers.

Verification

Current local verification on ae2047abec598989a10bea28d858e01e6b6b2f5f:

• Build Tests/UnitTestsParallelizable: passed
• DimAutoTests text-focused tests: 67 passed
• TextFastPathRenderTests: 5 passed
• SetRelativeLayoutTests: 10 passed
• Full UnitTestsParallelizable: 17,484 total / 0 failed / 17 skipped
• Full UnitTests.NonParallelizable: 74 total / 0 failed / 2 skipped

Pull Request checklist

• My code follows the style guidelines of Terminal.Gui
• My code follows the Terminal.Gui library design guidelines
• I ran dotnet test before commit
• I have made corresponding changes to the API documentation (using /// style comments)
• My changes generate no new warnings
• I have checked my code and corrected any poor grammar or misspellings
• I conducted basic QA to assure all features are working

🤖 Generated with Claude Code

[harder]

P1 (formatter constraints lost on the widened fast path) — resolved in ae2047a

Confirmed the bug with a probe: a View { Width = 5, Height = 2, WordWrap = true } had constraints 5×2 after layout, but after a fast-path Text change ConstrainToWidth/ConstrainToHeight were both null while NeedsLayout == false. Since GetLines() treats a null width as int.MaxValue, wrapped/clipped fixed-size text could render incorrectly until some later layout restored the constraints.

Root cause: UpdateTextFormatterText() clears the constraints, and the widened fast path then skipped SetRelativeLayout() — including its post-resolve cleanup that restores them from GetContentWidth()/GetContentHeight().

Fix:

• Extracted that cleanup into a shared FinalizeTextFormatterConstraints(), called by both SetRelativeLayout() and the fast path, so the fast path leaves TextFormatter in exactly the state a full layout pass produces.
• Renamed the helper to TryRedrawWithoutLayout() (it now owns the redraw-only handling: finalize constraints → mark NeedsFormat → SetNeedsDraw).

Testing

Beyond the requested constraint-survival coverage (fixed-size and one-axis-auto, with WordWrap), I ran a deeper probe pass with temporary harnesses (since removed):

• Render-equivalence sweep comparing the isolated fast path (laid out only when the setter requests it — no masking Layout()) against a full-layout control on Frame, both TextFormatter constraints, and rendered driver contents, across width dims (Text-auto / min / max / fixed) × height dims (Text-auto / fixed) × WordWrap × a multi-step text sequence — all identical. Verified non-vacuous (removing the finalization makes the fixed-dim cases diverge).
• Also probed CheckBox (overrides UpdateTextFormatterText, now called eagerly — idempotent), Pos.Align sibling groups, fixed parents with subviews, reentrant TextChanged, and a 100-tick clock simulation (zero frame drift, no ancestor propagation). No unintended consequences.

The high-value probes were kept as permanent tests: TextFastPathRenderTests (render-equivalence for fixed-size wrap/clip and max-constrained auto wrapping), plus clock-drift, reentrancy, and constraint-survival cases.

Results: UnitTestsParallelizable 17467 passed / 0 failed; UnitTests.NonParallelizable 72 passed / 0 failed; no new warnings.

[Copilot]

Pull request overview

Optimizes View.Text updates to avoid scheduling a full layout pass (and ancestor NeedsLayout propagation) when changing text would resolve to the same Frame, while still ensuring correct redraw and TextFormatter constraint behavior. This targets the performance issue described in #5499 (e.g., clock-like labels updating frequently without changing size/position).

Changes:

• Refactors layout frame resolution into TryComputeRelativeFrame and extracts FinalizeTextFormatterConstraints so both normal layout and the new text fast path share the same computation and formatter finalization.
• Updates View.Text setter to attempt a redraw-only fast path when a predicted frame matches the current frame and the dims are safely resolvable.
• Adds focused diagnostics and end-to-end render comparison tests to validate redraw-only behavior and formatter constraint preservation.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.

File	Description
Terminal.Gui/ViewBase/View.Layout.cs	Extracts frame prediction and formatter constraint finalization to share logic with the text fast path.
Terminal.Gui/ViewBase/View.Text.cs	Adds TryRedrawWithoutLayout to skip SetNeedsLayout() when predicted Frame is unchanged, while still forcing format+draw.
Tests/UnitTestsParallelizable/ViewBase/Layout/Dim.AutoTests.TextOptimization.cs	Adds diagnostics covering same-frame text updates, propagation behavior, and guards for unsafe cases.
Tests/UnitTestsParallelizable/ViewBase/Layout/TextFastPathRenderTests.cs	Adds end-to-end rendering parity tests comparing fast-path redraw vs forced full-layout control.

[tig]

Very nice.