Confirmed cause: on battery in a power-saving plan, Windows applies Power
Throttling (EcoQoS) to background work. StepForge records with its window
hidden, so the frame-capture worker renderer (plus the GPU and screen-capture
utility processes feeding it) get CPU-throttled. The throttled worker can't
sample the screen fast enough, so every click finds no fresh pre-click frame
and falls back to a slow post-click fresh shot — producing out-of-order,
dropped steps. It only reproduced on battery; plugged in (where EcoQoS stays
off even in eco mode) it worked. The capture log showed every click detected
but every one reporting "no frame qualified", with a ~4.6s stream startup.
Fixes:
- Chromium switches (disable-background-timer-throttling,
disable-renderer-backgrounding, disable-backgrounding-occluded-windows) so
Chromium stops de-prioritising and timer-throttling the hidden worker.
- New app/win-power.js opts the OS processes out of EcoQoS via
SetProcessInformation(ProcessPowerThrottling, EXECUTION_SPEED off) and
raises them to high priority. Applied to all live Electron processes when a
session starts/resumes, and to the worker renderer the moment it is created
(before it begins streaming). Best-effort, no-op off Windows.
The earlier mouse-hook EcoQoS opt-out already fixed click *detection*; this
fixes the frame-capture side that the same throttling was breaking.
