[Bug]: Sluggishness? (.deb)

[gellenburg]

What happened?

I'm not sure if this is a bug, but just letting you know that using the .deb version of the app, it is VERY slow and sluggish, with it taking a very long time even to click between categories in the Settings. My specs are definitely not low-end. (AMD Ryzen 5900/24 core, 128GB RAM, (3) RTX-3090 GPUs (72GB VRAM total), Ubuntu 26.04, KDE/ Plasma 6.6.6, Wayland.

Also, it appears that some preferences/ settings aren't being remembered between session/ app launches. I have to constantly turn off the "sepia" colors and every time I launch the app they come back.

Steps to reproduce

Download and install the .deb and set it up.

The app is very sluggish.

Expected behavior

Not for the UI to be slow and sluggish.

Environment

Desktop (Tauri — Linux)

Version

1.26.0

AI provider in use (if relevant)

Not relevant / no AI involved

Console errors / logs (if any)

Before submitting

• I searched existing issues and this is not a duplicate
• I am not reporting a security vulnerability (those go to Private Vulnerability Reporting)

[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.