mirror of
https://github.com/heygen-com/hyperframes.git
synced 2026-11-15 22:08:03 +00:00
Vance Ingalls
926c4c223e
When the host has no hardware GPU (SwiftShader software rendering), Chrome's `HeadlessExperimental.beginFrame` stalls the compositor on shader-heavy frames — the CDP call hangs and the render eventually fails with `beginFrame timed out` at protocolTimeout (default 5 min). This was reproduced on a CPU-only Linux sandbox during the hf#677 BeginFrame spike and is likely the same root cause as the earlier Mac-Docker timeout that the HDR-only guard in `captureHdrStage.ts` partially mitigated. The existing per-stage guard (`cfg.forceScreenshot = true` for the layered HDR composite) is too narrow — the issue is GPU-presence, not HDR-vs-SDR. SDR renders also stall on a software-renderer host. Fix: in `acquireBrowser`, resolve `browserGpuMode` (cheap — the probe Promise is cached for the process lifetime) and force `captureMode = "screenshot"` whenever it resolves to "software", regardless of platform or binary. Defensively strip BeginFrame-only chrome flags (`--enable-begin-frame-control` etc.) from the launch args in the same path — leaving them in screenshot mode produces blank captures because the compositor waits for beginFrames the engine no longer sends. Mirror the same gate in `frameCapture.ts`'s preMode computation so the chromeArgs are built without BeginFrame flags up front (the strip in `acquireBrowser` is belt-and-braces for any other caller). A one-time `console.warn` documents the resolution path for operators when the guard actually changed the outcome (Linux + headless-shell only — silent on the always-screenshot platforms and on hardware hosts). Note: on `main` as-is the layered HDR path already forces screenshot mode unconditionally, so the SDR-software-renderer case is the load-bearing one this PR fixes. The broader guard also keeps the engine safe once any future BeginFrame-alpha work lands on top. Tests cover: software → screenshot + BeginFrame flag stripping, hardware → beginframe preserved, forceScreenshot=true still wins, one-time software-GPU warning, no warn on macOS (already screenshot anyway). — Vai