Frontend burns 20–45% of a CPU core while completely idle (continuous per-frame Layout/Paint + timer churn)

Environment

• Blinko: v1.8.8, self-hosted, official Docker image, behind an nginx reverse proxy (HTTPS)
• Client: Google Chrome 150.0.7871.114 on Ubuntu 26.04, running Blinko as an installed PWA ("open as window"); also reproduces in a regular tab
• Hardware: Framework 13 laptop (i7-1260P) — relevant only because the constant CPU burn is what made this visible (fan noise / battery)

Symptom

The Blinko renderer process consumes ~20–45% of one CPU core continuously while the app is fully idle — no user input, no visible UI changes, window unfocused. Measured with OS-level per-process CPU sampling over 12-second windows, repeatedly, across several days:

• With the background animation setting enabled: up to ~47% of a core
• With background animation disabled: still ~20–35% of a core, sustained indefinitely
• The burn is network-silent — no polling/requests while idle, so it's purely a client-side render/timer loop
• Persists across page reloads, fresh browser starts, and a full OS reboot (every fresh renderer process shows the same signature)

Isolation done (why I believe it's Blinko's frontend, not my setup)

• Extensions ruled out: reproduced in a PWA window with all extensions disabled (Grammarly, which inflates editor CPU on its own, was explicitly disabled in all profiles — the burn is unchanged without it)
• Differential test: closing only the Blinko window removes exactly the hot renderer process; reopening it brings a new one with the same idle burn
• Other PWAs/tabs on the same machine idle at <1–8% of a core

DevTools Performance profile (idle on /?path=todo)

An idle recording (no interaction) shows the page doing per-frame layout and paint work with no visible change. Bottom-up top buckets:

• Layout ≈ 1.4 s, Paint ≈ 1.1 s, Layerize ≈ 0.9 s of self-time dominating the recording
• Constant timer churn: repeated Timer fired / repeatEvent entries with setInterval/clearInterval cycles

So something re-invalidates layout every frame even when the UI is static. Possible suspects from the outside:

• an animation loop that keeps running even when the "background animation" setting is off (the setting reduces but does not eliminate the burn),
• the frosted-glass / backdrop-filter styling forcing continuous compositing (related: #673),
• a requestAnimationFrame/interval loop that never idles when the document is unfocused/hidden.

Steps to reproduce

1. Self-host Blinko v1.8.8 (Docker), open it in Chrome (tab or installed PWA), log in
2. Leave it on the main or todo view, hands off the keyboard
3. Watch chrome:// Task Manager (Shift+Esc) or an OS process monitor → the Blinko renderer sits at 20–45% of a core forever
4. DevTools → Performance → record ~15 s without touching anything → continuous Layout/Paint/Layerize + timer activity

Expected

An idle note-taking app should draw ~0% CPU (Chrome throttles hidden/static pages to that; Blinko's constant layout invalidation defeats it). On laptops the current behavior means permanent fan noise and measurable battery drain for a pinned PWA.

Happy to attach full DevTools traces or run instrumented builds if that helps.

Trace-20260711T135900.json.gz

---

Environment

• Blinko: v1.8.8, self-hosted, official Docker image, behind an nginx reverse proxy (HTTPS)
• Client: Google Chrome 150.0.7871.114 on Ubuntu 26.04, running Blinko as an installed PWA ("open as window"); also reproduces in a regular tab
• Hardware: Framework 13 laptop (i7-1260P) — relevant only because the constant CPU burn is what made this visible (fan noise / battery)

Symptom

The Blinko renderer process consumes ~20–45% of one CPU core continuously while the app is fully idle — no user input, no visible UI changes, window unfocused. Measured with OS-level per-process CPU sampling over 12-second windows, repeatedly, across several days:

• With the background animation setting enabled: up to ~47% of a core
• With background animation disabled: still ~20–35% of a core, sustained indefinitely
• The burn is network-silent — no polling/requests while idle, so it's purely a client-side render/timer loop
• Persists across page reloads, fresh browser starts, and a full OS reboot (every fresh renderer process shows the same signature)

Isolation done (why I believe it's Blinko's frontend, not my setup)

• Extensions ruled out: reproduced in a PWA window with all extensions disabled (Grammarly, which inflates editor CPU on its own, was explicitly disabled in all profiles — the burn is unchanged without it)
• Differential test: closing only the Blinko window removes exactly the hot renderer process; reopening it brings a new one with the same idle burn
• Other PWAs/tabs on the same machine idle at <1–8% of a core

DevTools Performance profile (idle on /?path=todo)

An idle recording (no interaction) shows the page doing per-frame layout and paint work with no visible change. Bottom-up top buckets:

• Layout ≈ 1.4 s, Paint ≈ 1.1 s, Layerize ≈ 0.9 s of self-time dominating the recording
• Constant timer churn: repeated Timer fired / repeatEvent entries with setInterval/clearInterval cycles

So something re-invalidates layout every frame even when the UI is static. Possible suspects from the outside:

• an animation loop that keeps running even when the "background animation" setting is off (the setting reduces but does not eliminate the burn),
• the frosted-glass / backdrop-filter styling forcing continuous compositing (related: #673),
• a requestAnimationFrame/interval loop that never idles when the document is unfocused/hidden.

Steps to reproduce

1. Self-host Blinko v1.8.8 (Docker), open it in Chrome (tab or installed PWA), log in
2. Leave it on the main or todo view, hands off the keyboard
3. Watch chrome:// Task Manager (Shift+Esc) or an OS process monitor → the Blinko renderer sits at 20–45% of a core forever
4. DevTools → Performance → record ~15 s without touching anything → continuous Layout/Paint/Layerize + timer activity

Expected

An idle note-taking app should draw ~0% CPU (Chrome throttles hidden/static pages to that; Blinko's constant layout invalidation defeats it). On laptops the current behavior means permanent fan noise and measurable battery drain for a pinned PWA.

Happy to attach full DevTools traces or run instrumented builds if that helps.

Trace-20260711T135900.json.gz