[ptescher]

Step 5 of plans/battlefield-latency.md (#95). Stacked on #124. Measurements are in plans/battlefield-latency-results.md.

Changes

• No rendering for a camera nobody watches. A drone's camera without a viewer, and a battlefield no app asks for, set Camera::is_active = false instead of rendering at 64 × 36. Each camera pays its own shadows, sky and exposure whatever its size. Six idle drone cameras took the 3D view from 72 to 185 ms a frame.
• Frame pacing (visualization_battlefield::pacing). After each frame the render thread waits for the GPU to finish the frame two before, for at most 500 ms. Bevy presents a window only when a camera draws into it, and towers_view draws into images, so nothing held the CPU back. It queued frames while the valley loaded, and the GPU stayed 13 frames (about 730 ms) behind for the rest of the game.
• wgpu 30 is added to visualization_battlefield, only for SubmissionIndex. It is the version Bevy uses, so the build still has one wgpu.

Measured (towers_view alone, with a client that pans like the app)

	3D view	Pictures a second	Request to arrival	Valley loads in
Before	185 ms a frame	4.8	936 ms	35 s
After	53 ms a frame	18.6	224 ms	25 s

In a game, in the app: not measured yet

Correction (second commit). An earlier version of this description said the app still draws about 5 times a second in a game, mostly because the 3D view's window covers it. That is not supported. Those numbers came from the test driver forcing draws of the app's window. In a test run, or when the app is started from a shell session, that window is not on screen, and macOS does not draw it. In a 4-minute practice game started that way, the app never once logged a draw rate.

The 3D view's own numbers above do not depend on the app's window, and stand.

The second commit:

• towers_view --hidden. The view keeps its window off screen, and the commander app starts it so. The view's cameras draw into images either way.
• A draw-rate log. The app logs how many times a second it draws: battlefield: the app draws N times a second, every 5 s.

Next: measure with the app on a screen, with a person panning the camera.

Tests

• Unit tests, written first: render_size for the drones' cameras and the battlefield, the pacer, the hidden window, and the app's arguments to the view. visualization_battlefield 10 passed, recreation_towers_view 6 passed, teleoperation_command 1 new.
• Tooling: cargo clippy on both crates: clean. cargo fmt: done.
• Not run: the whole workspace suite and --selftest. The sim's window presents, so it has its own pacing, and nothing here touches the flight model.

🤖 Generated with Claude Code