Changing the active session rebuilds the entire terminal grid, reattaching every WebView2 #103

Found during the pre-release code review of v0.6.0..HEAD.

What happens

MainWindow reacts to every MainViewModel.ActiveSession change by calling RefreshTerminalLayout():

if (args.PropertyName == nameof(MainViewModel.ActiveSession))
{
    ...
    RefreshTerminalLayout();
    UpdateSidebarActiveState();
}

and that method starts by tearing the whole grid down:

private void RefreshTerminalLayout()
{
    TerminalGrid.Children.Clear();
    TerminalGrid.RowDefinitions.Clear();
    TerminalGrid.ColumnDefinitions.Clear();

So switching sessions detaches and reattaches every live WebView2 from the visual tree. WebView2 is an HwndHost — reparenting it is not a cheap layout operation.

Why it's now worth fixing

The wiring comment says "Single mode needs this", and that's the whole story: in Single layout the active session determines which pane is visible, so the rebuild is genuinely required. In every multi-pane layout — TwoByTwo, SixColumn, ThreeByThree — the set of visible panes does not change when the active session changes. Only the highlight does, and UpdateActiveTerminalHighlight already handles that on its own.

So for the layouts power users actually run, the rebuild is pure waste on a path that now fires much more often: #93 made clicking or typing in a pane promote it, so this runs on ordinary interaction rather than only on sidebar clicks.

Suggested fix

Skip the rebuild when the visible pane set can't have changed:

• Single (and any layout showing exactly one pane) → rebuild, as today.
• Multi-pane → skip, unless the effective group filter changed. Note InlineHeaders mode derives EffectiveActiveGroupId from ActiveSession, so there the pane set can change with the active session; FilterStrip mode uses the explicit tab and cannot.

UpdateSidebarActiveState / UpdateActiveTerminalHighlight should keep running unconditionally — they're the parts that actually need to react.

Related

• fix(terminal): make the pane you click or type in the active session #93 — made this path hot by promoting on click/type.
• The SetBorderColor idempotence fix in 456cd87 addressed border repaints on this same path, but not this much larger cost.
• perf: session restore on startup is fully sequential (~131s for 25 sessions; launch cost, not sleeps) #82 — same "scales badly with session count" theme; this is a per-interaction cost rather than a startup one.