Fling: the vsync clock, the frame ask, and a report that can say what it measured

Iris, from her phone: "some stuttering when flinging in particular.
Harder to notice with my finger directly moving the scroll." Her fling
phase was 103fps on a 120Hz screen at p50 6.3ms.

Two of the four things found are corrections to the instrument, not the
renderer. The swapchain acquire -- `get_current_texture`, which *blocks*
until the compositor frees an image -- was inside the span the report
called iris's CPU work, so a fling comfortably ahead of the display read
as milliseconds of being slow. A frame is now three measured parts
(`FrameParts`: build, acquire, submit), per phase as well as per run. And
nothing could say a frame was never *produced*: `late` counts frames that
cost too much, which a reader does not see, while a frame that never
happens leaves the last one up for two refreshes, which is the stutter.
`PhaseStats::missed` counts vsyncs nothing was drawn for. It closes on
the emulator: 1548 frames + 452 missed over 33.0s at 60Hz is 1980
vsyncs.

The other two are the frame loop. `Choreographer.postFrameCallback`
schedules for the next vsync after the call, and iris asked at the *end*
of the callback -- so any frame whose work ran past the boundary
registered too late and got the vsync after, one frame over budget
silently costing a second. It is asked for immediately after
`tick_animations` now, on both backends. And the fling was advanced on
`Instant::now()` rather than the vsync `do_frame` carries: frames are
presented on an even cadence whatever clock computes them, so sampling
the spline at "whenever the callback ran" moves the content unevenly with
no frame late enough to appear in any report -- and a drag never had it,
which is the asymmetry Iris described. `PointerClock` is `DeviceClock`
and the view keeps one, anchored by whichever of a touch or a frame comes
first, so a fling is advanced on the clock its velocity was measured on.

`opt-level` for the Android release build goes from "s" to 3. The table
in RUST.md picked "s" on bytes alone; over the same warm fling eight
times iris's own per-frame work is p90 0.15ms/p99 0.42ms at "s" against
p90 0.09ms/p99 0.26ms at 3, for 1.8 MB of arm64 APK.

`app-rust/tests/fling_profile.rs` is the rig that established what a
fling frame actually costs and is kept for next time (Iris: "please keep
the profiling rig around for future use"): only one frame in six lays
anything out, and the multi-millisecond spikes are all first-pass.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

AGENTS.md

@@ -389,6 +389,21 @@ Each exists because something was invisible without it.
   since the rig lives in iris and the app's examples do not). The emulator is for JNI, the IME, insets, the surface
   lifecycle and one verification run before a build goes to the phone --
   not for iterating on layout.
+- **`app-rust/tests/fling_profile.rs`** is what a fling frame costs on
+  the CPU, at layer 1 -- `cargo test --release --test fling_profile --
+  --ignored --nocapture`, from `app-rust/`. It flings the real transcript
+  screen over the bench fixture eight times, out and back, and prints the
+  per-frame distribution with a count of how many frames did any layout at
+  all. `#[ignore]`d and assertion-free, so `run-tests.sh` neither runs it
+  nor can fail on it; **release or the numbers mean nothing**, since text
+  shaping dominates. Two things it established on 2026-09-09 that are
+  worth not re-deriving: only about one fling frame in six lays anything
+  out (the rest are moved on the GPU through `move_offsets`), and the
+  multi-millisecond spikes are all in the *first* pass over a stretch of
+  transcript -- every later pass over the same rows is p99 0.26ms. So a
+  warm fling is not CPU-bound in iris, and a phone report showing
+  otherwise is measuring something else. It cannot answer anything about
+  the GPU, the swapchain or the phone's own clock.
 - **The emulator is a GLES rig, deliberately** (Iris, 2026-09-08;
   docs/RUST.md). Its guest has no hardware Vulkan -- only SwiftShader
   in software -- while its GLES *is* the host's real GPU through virgl at