a3946e5005
The named experiment was to attach the fast probe at t=0 so the boot title could not be missed. Done, default config, English: 2391 frames in 600.4 s = 3.98 fps; max glyph 0; hits 0 Ten minutes sampled four times a second FROM LAUNCH, no green-(A) glyph. So "the plate only shows in an early boot window I keep missing" is mine and refuted -- the third explanation refuted in three iterations. Then the check that should have come first. Splitting the raw root grab into bands: y 0- 44 (GTK menu bar) 100.00% non-black mean 210.50 y 45-719 (game surface) 0.08% non-black mean 0.07 The game is rendering black, reproducibly across back-to-back samples, while the guest is alive and polling input (XamInputGetKeystrokeEx past 1201 calls) and MEM-WATCH keeps reporting. The crop and every pixel oracle were correct; there was nothing on the surface to detect. What this does NOT do is retroactively explain the earlier failures, and claiming so would be the fourth over-reach in a row. Those runs had content: run 2 sampled mean 33.1, run 3's classifier measured real frame-to-frame rmse, the gamma_type=0 run measured mean 122.8. The failure mode CHANGED over the session; black is the newest and worst. Hypothesis for the regression, untested: canary's shader/pipeline cache is 47 MB and was last written 23:49 on Aug 28, during the failed runs, and this session has kill -9'd the emulator repeatedly. The test is to move cache* aside and boot again -- one line and one run, not done. Two METHOD lines: ask whether the screen is drawing anything before explaining why a feature of it is missing; and a newly found fault does not retroactively explain older failures.