Tyler
f580759337
Template tests / tests (push) Successful in 1m41s
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.