docs(perf): the p99 capture owed on wgpu 30 -- presents are now even

#570 moved the renderers from wgpu 29 to 30, changing the present call
(Queue::present) and adding an explicit surface colour space. The frame
pacing on the new path had not been measured; this is that measurement,
taken as an A/B rather than a lone number, because a p99 in isolation
reports the host as much as the code (see the v2.3.3 F5 section).

Method: v2.9.2 (4bbc3b3, wgpu 29, built in a worktree) against 9dd64f2
(wgpu 30), run alternately old/new/old/new for 45 s each with
RUSTYNES_PERF_LOG=1 on the CC0 flowing_palette.nes (perf_capture.sh's
default). Captures started once the one-minute load average was under 2.
The config was identical and read from the CSV headers: run-ahead 0, rewind
on, Mailbox, 119.991 Hz Wayland monitor. All four pass perf_log_check.py
with present_discarded=0.

Result, consistent in both pairs:
  presented p50  5.45 / 5.70 ms  ->  8.36 / 8.35 ms
  presented p95 15.63 / 15.67    -> 11.38 / 10.35
  presented p99 16.93 / 16.94    -> 11.97 / 11.70
  rwait p95     14.68 / 14.47    ->  8.48 /  8.45
  produced max  27.0 / 26.9      -> 19.0 / 19.0
  cost p95       2.99 / 2.98     ->  2.95 / 2.94
Both builds present at the monitor's rate (mean 8.37 ms). Under wgpu 29
those presents came in bunches; under wgpu 30 they land one vblank apart.
Emulation cost is unchanged.

Limits, stated in the doc: one host, one ROM, Mailbox only (not Fifo, 60 Hz
or run-ahead), present timing rather than what reached the eye, and not
attributed to a specific wgpu change, since the present-path move and the
colour-space field landed together. The raw CSVs stay in the session
scratchpad.

This closes the "p99 frame-pacing capture owed on wgpu 30" item carried
since #570.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014qfTKi2M3swo7qnwvYCkDj

Author: doublegate

CHANGELOG.md

@@ -52,6 +52,10 @@ cycle-accurate core later replaced.
     removed the day a fixed release ships. The wgpu 30 API changes (present on
     the queue, surface colour space, adapter limit buckets, a fallible mapped
     range) keep the picture and limits exactly as before.
+    Measured afterwards on a 120 Hz Wayland desktop (Mailbox): frames are now
+    presented one refresh apart instead of in bunches. The median present
+    interval went from 5.5 to 8.4 ms and the p95 from 15.6 to 10.4-11.4 ms, in
+    two alternating A/B pairs against v2.9.2 (`docs/performance.md`, v2.9.3).
   - egui 0.36 hands each texture several ordered updates per frame and asserts
     that a frame's texture updates are never dropped unapplied. Every update is
     now applied in order, and a detached tool window that closes between

docs/performance.md

@@ -985,6 +985,53 @@ borrowed bytes only. Working around it with a raw framebuffer pointer across the
 FFI would be new `unsafe` that nothing here can verify. It waits for that
 UniFFI release.
 
+### v2.9.3 — frame pacing after the wgpu 29 -> 30 move (#570): presents are now even
+
+**Finding: the move to wgpu 30 made present intervals regular on this host.
+No code was changed for it.** #570 changed the present call
+(`Queue::present` instead of `SurfaceTexture::present`) and made the surface
+colour space explicit (`Auto`). The p99 capture owed since then was taken as
+an A/B, not as a single number.
+
+**Method.** Two release frontends on one host: v2.9.2 (`4bbc3b31`, wgpu 29)
+from a worktree, and `9dd64f2e` (wgpu 30). They ran alternately (old, new,
+old, new), 45 s each, with `RUSTYNES_PERF_LOG=1` on the CC0
+`tests/roms/assorted/flowing_palette.nes`, which is `perf_capture.sh`'s
+default. Captures started once the one-minute load average was under 2.
+Configuration, identical for both and read from each CSV header and the
+config file: run-ahead 0, rewind on, present mode Mailbox, a 119.991 Hz
+Wayland monitor. Every capture passed `perf_log_check.py` with
+`present_discarded=0`, so the window was on screen throughout. Values are the
+mean over the 36 per-second rows after warm-up.
+
+| | old 1 | new 1 | old 2 | new 2 |
+| --- | --- | --- | --- | --- |
+| presented mean (ms) | 8.38 | 8.37 | 8.38 | 8.37 |
+| presented p50 | 5.45 | **8.36** | 5.70 | **8.35** |
+| presented p95 | 15.63 | **11.38** | 15.67 | **10.35** |
+| presented p99 | 16.93 | **11.97** | 16.94 | **11.70** |
+| redraw wait (`rwait`) p95 | 14.68 | **8.48** | 14.47 | **8.45** |
+| produced p99 (checker) | 17.96 | 17.69 | 18.18 | 17.76 |
+| produced max (checker) | 27.0 | 19.0 | 26.9 | 19.0 |
+| cost p95 (checker) | 2.99 | 2.95 | 2.98 | 2.94 |
+
+**Reading it.** Both builds present at the monitor's rate (a mean of 8.37 ms
+is one 120 Hz vblank), so each NES frame is shown twice. The difference is
+how evenly those presents are spaced. Under wgpu 29 they came in bunches: a
+median of 5.5 ms but a p95 of 15.6 ms, meaning a short gap, then a long one.
+Under wgpu 30 they land one vblank apart (median 8.36 ms, p95 10.4-11.4 ms),
+and the redraw handler's wait shrinks to one vblank. The emulator's own
+produce cadence changed little: produced p99 is about 0.3 ms lower, and its
+worst interval dropped from 27 to 19 ms. Emulation cost is unchanged. Both
+pairs agree in direction and roughly in size.
+
+**What it does not show.** One host, one ROM, one configuration (Mailbox, 120
+Hz, Wayland). It is not measured under Fifo, at 60 Hz, with run-ahead, or on
+another GPU or compositor. It is a measurement of present timing, not of what
+reached the eye. It is also not attributed to a specific wgpu change: the
+present-path move and the colour-space field landed together. Raw CSVs are in
+the session scratchpad, not the repository.
+
 ### v2.9.1 — the Vs. `DualSystem` serialize, adopted; and `ab_check.sh` compared the reference with itself
 
 **Decision: `VsDualSystem::snapshot_into` ADOPTED (serialize −88.9% and