Cache theme::resolve_theme() result in render — avoid unconditional recomputation per frame

[MasonRhodesDev]

Context

Render architecture audit from #203. theme::resolve_theme(window, theme_mode) is called unconditionally at the top of AnotherOneApp::render on every frame — at 16ms ticks during active use, that is ~62 calls per second for a value that changes only when the user explicitly toggles the theme.

Location

app/src/app.rs — first lines of AnotherOneApp::render, immediately after control_registry.borrow_mut().clear().

What to do

Cache the resolved theme on AnotherOneApp (e.g. cached_theme: Option<Theme>). At the top of render, only call resolve_theme when theme_mode has changed since the last frame (compare against a stored last_theme_mode). The terminal snapshot rebuild that also triggers on theme change (a few lines later) is already gated on the result — keep that gate.

Small change, zero architectural risk, measurable reduction in per-frame work.

[MasonRhodesDev]

Research findings

Is resolve_theme actually expensive?

No — it is a pure, allocation-free enum match. On desktop, system_prefers_dark() is a stub that compiles away entirely; the only real work is window.appearance(), a single GPUI accessor. This is a micro-optimization in isolation.

However, there are two concrete bugs in the same block worth fixing together:

1. resolve_theme is called twice per frame — once indirectly via chrome_bg_for_mode(window, theme_mode) → app_theme → resolve_theme, and once directly on the next line.
2. The else branch unconditionally calls set_terminal_theme(resolved_theme) even when the theme hasn't changed — storing the same value already in the AtomicU8. Dead work on every stable frame.

Types involved

Both ResolvedTheme and ThemeMode are Copy + PartialEq — no new field on AnotherOneApp is needed. current_terminal_theme() reading the global atomic already serves as an implicit cache.

Exact location (app/src/app.rs ~line 17828)

let chrome_bg = theme::chrome_bg_for_mode(window, theme_mode);  // resolve_theme call #1
let resolved_theme = theme::resolve_theme(window, theme_mode);  // resolve_theme call #2
if theme::current_terminal_theme() != resolved_theme {
    theme::set_terminal_theme(resolved_theme);
    // … rebuild terminal snapshots …
} else {
    theme::set_terminal_theme(resolved_theme);  // dead store: value already correct
}

Minimum viable fix (3 lines deleted)

Drop the else branch. The atomic is initialised in AnotherOneApp::new before the first render.

     if theme::current_terminal_theme() != resolved_theme {
         theme::set_terminal_theme(resolved_theme);
         // … snapshot rebuild …
-    } else {
-        theme::set_terminal_theme(resolved_theme);
     }

Full fix (~9 lines)

Add a helper in theme.rs so the resolved value can be reused for chrome_bg, eliminating the second resolve_theme call:

// theme.rs
pub fn app_theme_from_resolved(resolved: ResolvedTheme) -> AppTheme {
    match resolved {
        ResolvedTheme::Light => light_theme(),
        ResolvedTheme::Dark  => dark_theme(),
    }
}

// app.rs — resolve once, reuse
let resolved_theme = theme::resolve_theme(window, theme_mode);
let chrome_bg = theme::app_theme_from_resolved(resolved_theme).chrome_bg;
if theme::current_terminal_theme() != resolved_theme {
    theme::set_terminal_theme(resolved_theme);
    // … snapshot rebuild …
}

Other per-frame work checked nearby

• window.set_rem_size() — GPUI setter, no-ops if unchanged. Not a concern.
• set_terminal_theme in new() — one-shot init, correct as-is.
• set_theme_mode — event-driven user action, not per-frame, correct as-is.

Acceptance criteria

• cargo build -p another-one passes with no new warnings
• Light / Dark / System theme modes all render correctly
• Toggling OS dark mode while ThemeMode::System is active still rebuilds terminal snapshots
• The else branch (dead atomic store) is gone
• resolve_theme called at most once per frame

Estimated scope

Minimum fix: −3 lines. Full fix: ~9 lines across theme.rs + app.rs. Safe to land in a single small PR with no architectural risk.