web: sustained ~50% CPU and maxed GPU while live-rendering a streaming session #49552

Activity

1. github-actions

   assigned

   Brendonovich

   on Sep 17, 2026
2. github-actions commented on Sep 17, 2026

   

   github-actionsBot

   on Sep 17, 2026 – with GitHub Actions

   Contributor

   More actions

   This issue might be a duplicate of existing issues. Please check:

   • [BUG - Desktop] High iGPU load 50% or more during task execution. #31664: High iGPU load 50% or more during task execution — same symptom (GPU pinned at max during streaming)
   • [Desktop] UI freezes after agent turns finish — renderer stuck in ResizeObserver loop; only force-quit + relaunch recovers #43355: UI freezes — renderer stuck in ResizeObserver loop — same mechanism (ResizeObserver → rAF loop causing excessive repaints)
   • app: timeline row reconciliation uses Effect deep equality on every stream delta #48434: Timeline row reconciliation uses Effect deep equality on every stream delta — same rendering pipeline, same streaming context
   • [Bug]: sustained high CPU and memory growth in long-running web sessions with large SQLite history #46341: Sustained high CPU and memory growth in long-running web sessions with large SQLite history — overlapping symptom space

   If these are separate from what you're reporting, please clarify how this differs. Otherwise, adding detail to one of the existing open issues may be more productive.
3. Idsa0 commented on Sep 17, 2026

   

   Idsa0

   on Sep 17, 2026

   Author

   More actions

   I compared each of the suggested duplicates:

   • [BUG - Desktop] High iGPU load 50% or more during task execution. #31664 — different client and root cause: v1 Desktop app (Electron, Windows 11), GPU burn from continuous CSS animations (clip-path progress bar, mix-blend-mode avatar spinner). This report is the v2 web client in a browser (Firefox 156, Linux/Wayland): sustained ~40–50% of a core in the tab's content process + GPU pinned at max clock, strictly correlated with incoming stream events, ~0 when idle, scaling with session content size. The CPU-heavy, event-correlated signature points at the re-render pipeline rather than compositor animation.
   • [Desktop] UI freezes after agent turns finish — renderer stuck in ResizeObserver loop; only force-quit + relaunch recovers #43355 — the same fragile Observer→rAF path, but presenting as a full renderer freeze (force-quit required); here it is sustained heavy load, no freeze.
   • app: timeline row reconciliation uses Effect deep equality on every stream delta #48434 — closest match: per-delta timeline row reconciliation (fix PR refactor(app): avoid deep equality in timeline row reconciliation #48435). That patch covers the row-equality part of the per-delta work; this report additionally covers the observer→rAF re-measure and scroll-reconcile chains, the resulting GPU compositing load, and the idle baseline. Happy to re-measure after refactor(app): avoid deep equality in timeline row reconciliation #48435 lands and update this issue.
   • [Bug]: sustained high CPU and memory growth in long-running web sessions with large SQLite history #46341 — server-side CPU/RSS/SQLite bloat; a different layer than client rendering.

   Keeping this open as the symptom-level report for the v2 web client (GPU measurements + bundle analysis); happy to close it if you'd rather consolidate tracking under #48434.
4. Lightningxxl commented on Sep 19, 2026

   

   Lightningxxl

   on Sep 19, 2026

   More actions

   Adding a data point from Desktop (Electron) 1.18.31 on macOS that supports the per-event re-render hypothesis and separates it from the idle ResizeObserver loop (#38296):

   • With 2-3 concurrent streaming sessions, the Desktop renderer bursts to ~178% CPU (near 2 cores) and the GPU helper to ~40-60%; load tracks streaming activity and falls when sessions idle.
   • Crucially, during streaming the ResizeObserver error rate drops (mean 2.4-3.4/min) vs when idle (mean 9.8/min, peak 82/min). So the streaming-time load is dominated by real re-render work (this issue), while the idle-time load is the self-sustaining ResizeObserver loop (Electron renderer unresponsive / crash due to ResizeObserver loop storm (layout thrashing) #38296). The two regimes are separable in logs by error rate.
   • Consistent with "per-event timeline re-rendering without batching": load scales with number of concurrent sessions and event rate.

   Suggests the batching/throttling fix here and the ResizeObserver guard in #38296 address two distinct cost components; fixing only one leaves the other.
5. opencodejr commented on Oct 28, 2026

   

   opencodejrBot

   on Oct 28, 2026

   More actions

   Thanks for the detailed measurements. I couldn't reproduce this in our automated sandbox: it has no desktop browser and no GPU, so it can't show the GPU and compositing load you describe. A maintainer will need to check it with a real browser profile.

   The closest existing report is #48434, which is still open. It found that timeline row reconciliation does a deep-equality comparison on every streamed delta, and that cost grows with session size. Its fix PR, #48435, was closed without being merged. That may be part of what you're seeing, but your report also covers the GPU load and the observer/requestAnimationFrame work, so this issue stays separate.

   A Firefox Profiler recording (https://profiler.firefox.com) taken while a session streams would help a maintainer narrow it down.
6. Idsa0 commented on Oct 31, 2026

   

   Idsa0

   on Oct 31, 2026

   Last edited by Idsa0

   Author

   More actions

   Update (v2.2.5) — residual isolated to always-on working-state animations; cost scales with display refresh rate

   Re-tested on v2.2.5 (Firefox, Linux). After isolating the cost, the residual is a different, continuously-running cost than what #60489 addressed.

   What it is / isn't. Two PRs shipped in the 2.2.3 release to address other slices of this symptom — #60489 (per-delta timeline row-equality; closes #48434) and #60481 (stops the ResizeObserver loop errors while rows grow; explicitly references this issue). Both cut per-frame/streaming overhead, but neither changes the compositor frame rate, and neither touches this cost — the remaining working-state GPU load is animation-driven. Cleanest isolation, on the same build and same display rate: animations off → working-state GPU ~0 %; animations on → sustained (~40 % at 60 Hz, ~70 % at the 144 Hz baseline).

   Mechanism (v2.2.5 web bundle). The working/thinking state carries a set of always-on CSS animations. The dominant one is the status label rendered by [data-component="text-shimmer"], which draws the label one animated span per character, each running an infinite text-shimmer-sweep keyframe animating background-position under background-clip:text (will-change: background-position) — a paint property, forcing a repaint each frame. It's accompanied by other working-state indicators, e.g. the busy tab mark [data-titlebar-tab][data-status=busy] [data-mark=busy] rendering a loader-v2 spinner (transform: rotate, compositor-cheap), plus pulse/caret opacity animations.

   Measured (Firefox Profiler, working state, no text streaming):

   	144 Hz	60 Hz
   Compositor vsync	~143 /s	59.5 /s
   Full paints	~142 /s	~55 /s
   WebRender frame builds	135.6 /s	59.2 /s
   CSS animations sampled / frame	~25	~24
   Content style/paint invalidations	125.0 /s	63.6 /s

   Same per-frame animation count at both rates; every compositor/paint metric scales linearly with display refresh rate (vsync-capped), and GPU utilization follows: ~40 % at 60 Hz → ~70 % at the native 144 Hz baseline (peaking while streaming, when the paint-heavy shimmer is active), reproducing the original high-GPU symptom at the native rate.

   Recordings: 144 Hz — https://share.firefox.dev/4if8h1v · 60 Hz — https://share.firefox.dev/4zqm0Zq

   Same persistent-animation GPU-burn class as #31664, scoped to named elements, and a real cost at any refresh rate (≈2.4× at 144 Hz vs 60 Hz).

   Shipped mitigation: prefers-reduced-motion / data-motion="reduce" sets animation: none on these elements (which is why disabling animations drops GPU to ~0 %).

   Suggested fixes:

   1. Render the shimmer as a single compositor-friendly sliding highlight (one transform/mask) instead of per-character background-position animations.
   2. Trim the count of always-animating working-state indicators.
   3. Pause them when the reasoning block is collapsed or the tab is backgrounded.

   Keeping this open as the element-level report for the v2 web client.