Skip to content

fix(tui): defer named-theme palette detection - #48570

Merged
rekram1-node merged 1 commit into
v2from
palette-fast-boot
Sep 12, 2026
Merged

fix(tui): defer named-theme palette detection#48570
rekram1-node merged 1 commit into
v2from
palette-fast-boot

Conversation

@rekram1-node

@rekram1-node rekram1-node commented Sep 11, 2026

Copy link
Copy Markdown
Collaborator

Summary

Terminal palette detection already starts before ThemeProvider mounts. Previously, startup always waited for that request before making the selected theme ready—even when a named theme such as opencode does not use terminal palette colors.

This keeps palette discovery exactly where it is and changes only what startup waits for:

  • system theme: wait for terminal colors, unchanged
  • named themes: continue palette discovery in the background and wait only for custom-theme discovery

The production diff is one five-line change in ThemeProvider; there are no timers, new public APIs, or cross-component lifecycle coordination.

Performance

Final formulation, 15 interleaved exact Bun 1.4.2 compiled runs through a non-backpressured PTY against the same warm server:

milestone before median after median
prompt bytes 401.2ms 97.3ms
immediate typed echo 418.4ms 113.8ms

The result varies with machine/load, but consistently removes the terminal palette detector's roughly 300ms timeout from named-theme readiness.

A separate corrected 30-run benchmark confirmed explicit system is flat (prompt bytes 445.1ms before vs 446.7ms after).

The PTY harness drains until EAGAIN; a one-call 5,502-byte frame arrives in 0.112ms median, avoiding terminal-control recorder backpressure that affected early measurements.

UX verification

scenario result
default opencode same stable colors/layout; visible sooner
other named/custom themes custom discovery is still awaited; palette discovery remains background-only
explicit system same palette wait and generated colors
explicit light/dark mode unchanged code path
terminal theme notification unchanged refresh path
switching to system palette discovery starts at the same absolute time as before
cleanup/shutdown unchanged; no new resources or listeners

Baseline and changed binaries were also captured after settling at narrow width for default and system configurations; stable visual output matched aside from randomized placeholder text.

Verification

  • TUI typecheck
  • Existing theme and lifecycle tests: 39 passed
  • Exact Bun 1.4.2 compiled build
  • Default and system terminal captures
  • Immediate input/echo probe

No new tests are added by this PR.

Named themes do not depend on terminal palette colors, but startup waited for
the shared system-theme palette request before marking the theme ready. Some
terminals answer palette support without answering every color query, adding
a roughly 300ms idle timeout before the useful frame.

Keep palette detection on the critical path for the explicit system theme.
For named themes, paint immediately and prepare the system palette after the
first frame so later theme switching remains available.

Compiled warm-server startup to Ask anything improves from 538ms to 215ms
for the default opencode theme. Explicit system theme startup remains flat
at 554ms to 546ms.
@rekram1-node
rekram1-node merged commit 0d8e641 into v2 Sep 12, 2026
10 checks passed
@rekram1-node
rekram1-node deleted the palette-fast-boot branch September 12, 2026 02:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant