Desktop idle CPU/power usage high on v1.19.7 (Windows) — tab status animation + bot polling

[Jonasren1911]

Environment

• Reasonix Desktop v1.19.7 (stable), commit 295b3f7
• Windows 11, 32-core
• WebView2 (Wails)

Note: measurements were taken on v1.19.7. The behavior was originally suspected on v1.19.6; the same animation code paths exist in both (checked against the main-v2 styles.css).

Symptom

Idle CPU/power usage is noticeably high when the window is visible and no AI activity is happening. Measured ~35% of one core sustained at idle (window visible, no interaction, no streaming). Minimizing the window drops renderer/GPU activity significantly, which points to foreground rendering work.

Measurement (A/B test, 39s samples each, window visible and idle)

Process	Animations ON	Animations OFF (system "animation effects" off)	Delta
Renderer (webview2)	4.8%/core	0.5%/core	-90%
GPU process	8.9%/core	2.6%/core	-70%
Main process (reasonix-desktop)	20.6%/core	21.3%/core	unchanged

Method: process CPU delta sampled over 39s with the window visible and idle; system prefers-reduced-motion toggled between runs (Windows 11 Settings -> Accessibility -> Visual effects -> "Animation effects").

Findings

1. Foreground animations cost ~11%/core at idle. The biggest offender appears to be the tab status dot:

   • desktop/frontend/src/styles.css L22817-22824: .tabbar__tab--active .tabbar__status runs tab-status-breathe 2.6s infinite and .tabbar__status--running runs tab-status-breathe-running 1.8s infinite
   • Both animate box-shadow (keyframes at L22836-22852), which cannot be GPU-composited — every frame triggers a main-thread repaint plus color-mix() recompute.
   • The element is always present: TabBar.tsx L255-260 renders .tabbar__status for every non-file tab, and there is always an active tab.
   • A global prefers-reduced-motion fallback exists (styles.css L25679-25688) so users can mitigate via OS settings, but the perpetual infinite animation is still unnecessary idle work for everyone else.

2. Main process stays at ~21%/core regardless of animations — this is the always-on IM bot (WeChat) polling: the process holds a persistent HTTPS connection to the ilinkai gateway and polls continuously even when idle. This is the larger of the two idle costs.

Suggested fixes

1. Replace box-shadow breathing on .tabbar__status with opacity/transform (compositor-friendly) and/or scope the animation to actual state changes instead of a perpetual infinite loop.
2. Add these selectors explicitly under prefers-reduced-motion (partially covered by the blanket rule at L25679, but worth being explicit).
3. Investigate bot polling frequency — a persistent connection should not require continuous CPU work when no messages are pending.

Related

• [Bug]: 最新版异常占用 CPU 特别验证 #6353 (macOS v2 branch, same class of "high CPU/energy" complaint)