[ptescher]

Step 1 of plans/battlefield-latency.md (#95): each picture of the battlefield now goes out with the camera it was rendered from, and the stillness gate is gone. Results are in plans/battlefield-latency-results.md.

Change

• One readback per frame. Each frame the 3D view spawns a ReadbackOnce, and its observer keeps the request that frame was rendered for. Bevy 0.20 extracts the readback with that frame and copies the texture after the frame's render graph, so the pairing is exact. The observer despawns the entity, because Bevy only removes the components.
• steady_request is gone (it sent a picture only after four still frames). visualization_battlefield::outbox::Outbox decides what goes out: the size asked for, not older than a picture already sent, and at most 60 a second.
• The driver times each draw of the window during the pan, and prints it with the measurement.

Evidence

• Unit tests: Outbox has 6 tests, written first. They failed to compile without it, and pass now. They replace the old steady_request test.

• Alignment while moving: screenshots taken in the middle of a pan show the map on the valley (the towers' circles in their clearings, the lake's shore). That is the slide the gate was added for, in be3b8be.

• A 3 s pan:

  	Before	After
  New pictures a second	0.3	14 to 23
  Picture out of date by (median)	544 ms	420 to 630 ms

Found: the commander app draws about 5 times a second while the 3D view runs

	The draw	The round trip	Draws in 3.6 s
3D view running	15 ms	140 to 200 ms	11 to 14
No 3D view	2 ms	6 ms	140

GPUI waits in next_drawable() while the 3D view, at about 100 ms a frame, keeps the shared GPU busy. The drones' cameras are not the cost: not watching them changed nothing. So the expectation «The picture keeps up with the camera» stays Status: pending, and step 5 (a lighter 3D view) is next.

Not run

--selftest and the whole workspace suite; nothing here touches the flight model. cargo clippy on the changed crate is clean, and CI runs the rest.

🤖 Generated with Claude Code