Files
BT411/context
arcattackandClaude Opus 4.8 56ca2f5c13 Mission loads 72s -> 4s: the wait screen was GPU-syncing every idle frame
The operator challenged the "inevitable ~minute" load (Task Manager
showed idle CPU) and was right.  Measured chain:

- A/B same box/egg: dev 7s, +glass 30s, +BT_DEV_GAUGES 72s+.
- Drain census: identical ~560-event make streams; 190 events/s in dev
  vs a metronomic 7/s in the console shape -- the loop, not the events.
- Stack sampling: 4/6 samples inside ExecuteIdle's wait-screen paint --
  GDI GetDC/FillRect on the D3DPOOL_DEFAULT offscreen surface forces a
  full GPU pipeline sync (~140ms/frame at glass window size).  The
  2026-07-22 flicker fix traded a cosmetic bug for a 25x load throttle,
  worst on the operator box (bigger window + gauge-window GPU work),
  with idle CPU because a GPU-sync stall isn't compute.

Fix (ExecuteIdle): the staging surface is D3DPOOL_SYSTEMMEM (GetDC is
pure CPU; survives Reset for free) uploaded via UpdateSurface, and a
change gate skips the whole idle frame unless the spinner phase
(12.5Hz) or state text changed -- between paints the loop runs free.

Result: console-shape load 72s+ -> 4.1s (BEGIN -> READY), drain at 345
events/s; every pod benefits (same code), and the all-ready launch gate
now waits on a seconds-scale slowest loader.  Permanent pre-run
diagnostics kept: the drain census + >50ms slow-event lines (EVENT.cpp,
stand down at scene-live; slow-event identity captured BEFORE Process
-- Receiver::Receive(Event*) deletes the event).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-07-23 08:51:14 -05:00
..