[Desktop/Tauri→Qt]: Linux responsiveness, Alt-Tab hang & memory — cross-renderer acceptance baseline

[gellenburg]

Summary

This issue began as severe packaged Linux .deb sluggishness plus preferences not surviving relaunch. Investigation has now separated it into multiple engineering problems with different ownership, severity, and migration value.

It should therefore serve as the cross-renderer desktop performance/lifecycle acceptance baseline for the Tauri → Qt migration, not as a requirement to perfect WebKitGTK before Qt work may begin.

Current decomposition

Track	Status	Treatment
Persistence/preferences	RESOLVED + FIELD VERIFIED	Preserve regression coverage
App-owned visual/performance cost	PARTIALLY HARDENED	Continue only portable/high-ROI work
WebKitGTK / Wayland / NVIDIA differential	RUNTIME/ENVIRONMENT CANDIDATE	Bounded diagnosis; no deep workaround architecture
Alt-Tab / background-resume hard hang	UNRESOLVED-OBSERVABLE	Classify owner; transfer semantic scenario to Qt
Abnormal WebKit process memory growth	UNRESOLVED-OBSERVABLE	Classify portable leak vs runtime amplification

What is already known

• The original preference/persistence defect is fixed and externally verified in a packaged desktop build.
• Reducing transparency/compositing-heavy visual effects and motion materially improved responsiveness on the affected Linux/Wayland/NVIDIA system, so there are real app-owned performance levers.
• The PWA remains more responsive under the same broad product workflow, preserving a useful browser reference baseline.
• Alt-Tab/background-resume hard freezes have been reproduced repeatedly during normal packaged use and can require force-kill.
• A separate WebKit process memory-pressure event reported roughly 26.7 GB footprint before termination. It may be related to the hang, but causality is not proven.

Architecture context

The adopted native target is Qt 6 + Qt Quick/QML backed by the renderer-neutral Rust Core, not a Qt-WebEngine recreation of the Tauri/WebKitGTK shell.

Therefore:

• WebKitGTK-specific defects are not automatically portable to Qt;
• application/Core/lifecycle/memory defects may be portable and must be fixed or explicitly owned;
• this issue must generate reusable acceptance evidence rather than open-ended WebKitGTK archaeology.

Decision vocabulary

For each non-trivial follow-up, record one of:

FIX
INSTRUMENT
MITIGATE
DEFER-TO-CORE
STOP-TAURI-LANE
TRANSFER-TO-QT-ACCEPTANCE

Also record:

severity = TM-0 / TM-1 / TM-2 / TM-3
root cause owner = app / shared-core / adapter / runtime / compositor / driver / unknown
renderer-neutral fix = yes / no
Qt/Core reuse = high / medium / low
Tauri-only coupling = none / low / medium / high

Portable-vs-runtime classification gate

Before further non-trivial #332 engineering:

1. App/shared-Core ownership — if state transitions, serialization, I/O, task scheduling, retained resources, editor models, queues, or application memory grow/stall, fix it because it can migrate with the product.
2. Adapter ownership — if a narrow Tauri lifecycle/adapter correction resolves the defect without creating new architecture, fix it.
3. Runtime/compositor/driver ownership — if the failure remains after app-owned work is bounded and correlates with WebKitGTK, Wayland, NVIDIA, DMABUF, compositor state, or WebProcess failure, preserve evidence and stop deep Tauri-specific engineering.
4. Unknown — instrument only until ownership is narrow enough to choose FIX, MITIGATE, or STOP-TAURI-LANE.

Tauri stop rule

Stop deep Tauri-specific work when all of the following are true:

• data-integrity/security risks are fixed or separately tracked as TM-0;
• app-owned duplicate work, deadlock, unbounded serialization, and portable memory leaks are fixed or ruled out;
• the residual materially correlates with WebKitGTK/compositor/GPU/host behavior;
• the remaining remedy would require broad/brittle Tauri-only work, global graphics overrides, runtime forks, or substantial WebKit-specific recovery architecture;
• a renderer-neutral acceptance scenario exists for Qt.

At that point classify the residual as RUNTIME-LIMITED or ENVIRONMENT-LIMITED, keep only a safe narrow mitigation if justified, and transfer the scenario to Qt acceptance.

Do not build product architecture around global WEBKIT_DISABLE_DMABUF_RENDERER, WEBKIT_DISABLE_COMPOSITING_MODE, __NV_DISABLE_EXPLICIT_SYNC, or equivalent overrides. These remain diagnostic levers unless reproducible evidence justifies a scoped compatibility decision.

Memory classification gate

The abnormal WebKit process footprint must be separated into two classes:

Portable/application leak

Examples:

• application/Redux/Core state grows without bound;
• editor models/resources accumulate;
• listeners/object URLs/tasks/queues leak;
• serialization buffers or retained snapshots grow indefinitely.

Action: fix before or during Qt migration because the defect may survive renderer replacement.

Renderer/runtime amplification or leak

App-owned heap/resources remain bounded while WebKit/WebProcess/GPU-side footprint grows abnormally.

Action: capture enough evidence to establish that distinction, then carry the same soak scenario into Qt rather than creating a WebKitGTK-specific recovery subsystem.

The goal is ownership classification, not explaining every internal WebKit allocation.

GOLDEN-DESKTOP-LIFECYCLE-332

This renderer-neutral scenario is both a Tauri diagnostic target and a required future Qt acceptance input:

1. Open a representative project and edit the manuscript.
2. Cross an autosave boundary.
3. Background the window for 5 seconds, return, and edit immediately.
4. Repeat for 20 Alt-Tab cycles.
5. Exercise 30-second and two-minute background intervals.
6. Exercise minimize/restore.
7. Navigate Settings and Writer Studio after resume.
8. Normal close and relaunch.
9. Repeat with a large representative project.
10. Run a 30-minute editing/memory session.
11. Run a longer soak appropriate to the target environment.
12. Execute the same semantic workload on PWA, Tauri, and Qt; GPUI may consume it later after separate admission.

Required outcomes

• no UI disappearance;
• no unbounded hang;
• no force-kill required;
• first click/caret/keyboard input after resume is acknowledged promptly;
• acknowledged edits survive;
• save/close/relaunch succeeds;
• no project corruption;
• memory growth is bounded or has an explicit measured explanation.

Cross-renderer benchmark record

Preserve comparable measurements where practical:

Metric / scenario	PWA	Tauri	Qt	GPUI if admitted
cold/warm start	baseline	baseline	target	future
Settings navigation latency	baseline	baseline	target	future
editor input latency p50/p95	baseline	baseline	target	future
scroll/frame consistency	baseline	baseline	target	future
Alt-Tab recovery	baseline	known issue	0 failures target	future
idle RSS	baseline	baseline	target	future
30-minute RSS / slope	baseline	baseline	target	future
long-soak peak RSS	baseline	baseline	target	future
save/autosave latency	baseline	baseline	target	future
large-project open/save	baseline	baseline	target	future
crash/force-kill count	baseline	baseline	0 target	future

Every packaged evidence record should name build SHA/release, runtime/toolkit version, OS, compositor, display protocol, GPU/driver, launch path, fixture/scenario version, and evidence maturity (LOCAL_ONLY, CI_ONLY, PACKAGED_LOCAL, PACKAGED_TARGET_ENV, FIELD_OBSERVED).

Qt handoff rule

#332 is a Qt migration acceptance baseline, not a prerequisite to perfect Tauri first.

Qt qualification must rerun the same semantic scenarios with Qt-native instrumentation and explicitly compare:

• input/interaction latency;
• GUI/render-thread behavior;
• process memory and long-session growth;
• background/resume and minimize/restore;
• large-project open/save/autosave;
• graphics backend/GPU identity on Linux/Wayland/NVIDIA;
• multi-GPU behavior where target hardware exposes it.

A residual Tauri runtime limitation may remain documented while Qt proves the equivalent workflow stable. This does not authorize unsafe early Tauri retirement; normal Qt Stable and Tauri retirement gates still apply.

Closure criteria

Close this issue only when one of these is true:

1. Tauri itself passes the packaged target acceptance scenario and the remaining performance/memory findings are resolved; or
2. portable/app-owned defects are resolved or separately tracked, residual Tauri limitations are explicitly classified/documented, Qt passes the equivalent packaged-target acceptance scenario, and the approved Qt Stable → Tauri retirement path owns the remaining runtime-specific limitation.

Until then, keep #332 open as the canonical cross-renderer lifecycle/performance evidence source.

[qnbs]

Investigated the .deb sluggishness and the "sepia keeps coming back" symptom together — fixes in #345 (`fix/332-tauri-desktop-reliability`).

Root cause confirmed (highest-confidence finding): the desktop build never read persisted state back at cold boot. Every save (autosave, manual save, the visibility-change flush) already routed through the Tauri-aware storage layer, but the app's boot-time hydration called a raw IndexedDB-only read with zero Tauri branching. On desktop, that read is always empty — every launch loaded as a brand-new user regardless of what was actually saved to disk. This is a strict superset of the reported "appearance preference resets" symptom: it's not just `appearancePreset` that never persisted, it was the entire project/settings state. Boot-time hydration now branches correctly and mirrors the save path (`services/appBootstrap.ts`).

Also fixed as part of the same investigation:

• First-launch settings default mismatch — a leftover `'default'` fallback that disagreed with the deliberate `'sepia'` default set elsewhere; only mattered for a genuinely first-ever launch.
• No flush before quit — closing the window could previously land mid-debounce and silently drop the last edit; quitting now always waits for any pending autosave to finish first.
• backdrop-blur GPU compositing cost — extended the existing reduced-transparency mitigation to also cover direct blur usage (not just the color-token layer it previously covered), and added a manual "Reduce transparency effects" toggle in Settings → Accessibility for desktops/window managers that don't expose the OS-level preference.
• Settings screen re-rendering on unrelated background activity — the Settings panel was rebuilding its entire context value on every render, so any unrelated background write anywhere in the app (autosave, AI activity) forced the whole Settings screen to re-render even while it wasn't the visible view.

What this does not claim: I can't run a packaged Linux `.deb` build in this environment, so I can't personally confirm how much these fixes move the needle on the sluggishness you measured on your hardware. The hydration bug alone is a serious, unambiguous defect regardless of its performance impact, and the other four items are real, verifiable contributing factors — but closing this out for good needs someone to actually install a build with #345 and re-test on the original hardware/DE combination. Leaving this open for that confirmation rather than closing preemptively.

If you're able to test once #345 merges, a report on whether Settings navigation and the sepia-persistence issue both feel resolved on your end would be very helpful.