Correcting my own previous commit, which concluded hardware GL required headful
and made `--gl hw` open a real window per clip. PLN, mid-batch: "stop opening
chrome windows lol cant we do this headless". Yes — and the conclusion was wrong
because I tested three launch modes and stopped at the first that worked.
Five headless modes plus headful, each asked what WebGL actually resolved to:
--use-angle=swiftshader -> SwiftShader (Subzero)
--use-gl=egl -> SwiftShader (Subzero)
--use-angle=vulkan -> SwiftShader (Subzero)
--ozone-platform=headless --use-angle=vulkan -> SwiftShader (Subzero)
--use-gl=angle --use-angle=gl-egl -> Mesa Intel UHD (CML GT2)
HEADFUL -> Mesa Intel UHD (CML GT2)
`--use-gl=angle --use-angle=gl-egl` reaches the real GPU with no window at all.
It is ONE FLAG WORD from `--use-gl=egl`, which silently degrades to software —
which is exactly why the original code read as correct and was not, and why the
comment claiming the hw path "falls back by simply measuring worse" survived so
long. It never fell back: 3.5 fps and 3.2 fps were the same software backend
measured twice, and two numbers that looked like measurement noise were one wrong
assumption.
Measured, landscape 1920x1080, same 30 s window each time:
swiftshader (headless) 3.5 fps captured
headful + real GPU 11.4 fps captured, page rendered 17
headless + gl-egl 17.8 fps captured, page rendered 542 of 542
Headless is FASTER than headful — no compositor in the path — and the capture
bottleneck disappears with it: captured frames now equal rendered frames, where
headful drained 346 of 516. So the earlier "the next lever is the capture path"
note was also an artefact of the wrong launch mode. 5x the software baseline,
comfortably past the under-5-fps guard, and no windows.
Lesson for the file: an early success is not a search. Two of the five modes
reach the GPU and three do not, and the three failures are indistinguishable
from each other by frame rate alone.
