[RFC]: adopt performance-first desktop optimization direction

[hiqiancheng]

Summary

Adopt a performance-first native desktop direction for TouchAI before implementation work starts. TouchAI is a desktop AI assistant built on Tauri 2 + Vue 3 + Rust, and the most important native-feel promise is perceptual performance: global shortcut to visible focused input, no dropped first keystroke, smooth search-window resize, responsive typing, stable streaming output, low hidden-window CPU, and honest memory accounting.

Motivation

The initial RFC direction covered broad native-feel work. The priority is now performance. Native feel should be judged first by whether the app appears immediately, accepts input immediately, avoids resize hitches, stays responsive while streaming, and does not keep expensive work running while hidden. UI convention cleanup remains useful, but it should follow measured hot-path improvements rather than lead the work.

Affected boundaries

• AgentService
• conversation runtime
• tool execution
• session persistence
• context construction
• instruction loading
• agent orchestration
• MCP integration
• database schema or migrations

Primary expected areas are desktop shell/windowing, search-window renderer behavior, IPC frequency, startup sequencing, and memory margin cost. If implementation expands into any checked RFC-first boundary above, that implementation PR must wait for explicit RFC acceptance.

Proposed design

Use the native-feel desktop decision framework with performance as the first lens:

• T4: performance is a property of perception. Optimize hotkey-to-visible latency, first-keystroke readiness, resize smoothness, typing responsiveness, and hidden-window idleness before generic benchmark work.
• T8: separate baseline cost from margin cost. Accept the Tauri/WebView baseline and focus on app-owned costs such as unnecessary renderer work, duplicated state, unbounded caches, and avoidable IPC.
• T6: cross boundaries intentionally. Treat every Tauri command/event as a performance contract; hot paths need low frequency, batching, typed payloads, and measurable latency.

Initial performance targets for follow-up PRs:

• warm global shortcut to visible focused search window under 200 ms;
• cold launch to usable search input under 600 ms where platform startup allows it;
• no dropped first keystroke after window show;
• no visible hitch during search-window resize/expand/collapse;
• no frame drops from synchronous layout or native calls during fast typing;
• near-zero background CPU when the main window is hidden;
• idle memory tracked as baseline vs app-owned margin before architectural changes.

Current hot paths to audit first:

• apps/desktop/src/views/SearchView/startup.ts for first-paint dependencies;
• apps/desktop/src/views/SearchView/composables/useSearchWindowResize.ts for ResizeObserver coalescing and resize IPC frequency;
• apps/desktop/src-tauri/src/core/window/resize.rs for native resize, centering, min-size constraints, Windows atomic frame updates, and animation guards;
• apps/desktop/src/services/NativeService/window.ts for renderer-facing IPC call shapes and batching opportunities.

Alternatives and trade-offs

Alternative 1: Continue broad native-feel UI cleanup first.
Trade-off: improves polish, but may leave the most user-visible performance problems untouched.

Alternative 2: Rewrite toward a Raycast-like native shell + system WebView + Node backend + Rust core.
Trade-off: strongest match to the reference architecture, but too disruptive for the current Tauri stack and unjustified before measured bottlenecks prove the need.

Alternative 3: Switch to Electron and theme aggressively.
Trade-off: simpler web runtime, but gives up direct control over native shell details and likely worsens memory/startup baseline.

Recommended path: incremental Tauri-native performance hardening. Preserve the current stack, measure the hot paths, then optimize startup, activation, resize, IPC frequency, idle CPU, and app-owned memory margin in small PRs.

Upstream references

• Native-feel cross-platform desktop skill: T4 performance perception, T6 intentional boundaries, T8 baseline vs margin memory.
• TouchAI existing architecture: Tauri 2 + Vue 3 + Rust, with current window/search/runtime boundaries in apps/desktop/src-tauri/src/core/window and apps/desktop/src/views/SearchView.
• Worktree RFC document: docs/rfc/0413-native-feel-desktop-direction.md.

Testing and rollout

Start with RFC/design and measurement work. Implementation should be split into small follow-up PRs:

1. development-only performance baseline/instrumentation for warm activation, first input focus, resize command count/latency, and hidden-window idle observations;
2. search-window resize optimization across useSearchWindowResize.ts and core/window/resize.rs;
3. startup and first-paint budget cleanup;
4. bundle/surface loading audit for the main search window;
5. memory margin audit separating WebView/Tauri baseline from app-owned allocations;
6. native UI convention cleanup after hot paths are measured or improved.

Verification for implementation PRs should include pnpm test:pr; desktop startup/window/search changes should also include pnpm test:e2e or documented CI-only evidence. Each performance PR should report before/after measurements for the specific path it touches.