Prediction horizon under varying weave cadence: EMA-smoothed setLatency makes cadence variance read as stutter (per-weave horizon needed)

[dfattal]

Observation (David, hardware, 2026-08-28)

Across a week of weave-cadence experiments on the win box (runtime #1257 gate + slot-partition builds, native 3DLuma avatar, Leia panel), perceived 3D quality tracks cadence steadiness, not update rate:

weave cadence	panel updates/s	David's verdict
steady (stock)	60	fine
steady (partition D=3: app 20 + repaints 40)	60	"tracking is great, no stutter, very good experience"
varying (gate hz30 adaptive: oscillating)	28–50	"pretty stuttery"
varying (partition v2 on VK tier)	45–50 unsteady	"stuttery"

A 45–50/s varying cadence looks worse than a steady 60 — and by more than temporal sampling explains. David's hypothesis: the head-position prediction is wrong per frame when the cadence varies. The SR runtime predicts from tracking history + a prediction horizon we provide via setLatency; if the horizon is a smoothed average while the actual weave-to-photon time varies frame-to-frame, every weave is derived for a head position at the wrong time → parallax error oscillating at the cadence-variation frequency → spatial judder that reads as stutter.

The code supports the hypothesis

src/drv_leia/leia_sr.cpp (ConfigureAdaptiveLatency, v2.6.4): the adaptive path smooths the weave interval with an EMA, default alpha 0.15 (LEIA_VK_LATENCY_EMA_ALPHA), plus a constant display term. An EMA with alpha 0.15 has a time constant of ~6 weaves — under a cadence oscillating between 28 and 50/s the estimate is always lagging and always averaged across two regimes, so the per-weave horizon error is on the order of half the interval spread (~±8 ms), which at a fast head motion (~0.3 m/s) is ~±2.4 mm of predicted-position error alternating frame to frame.

The comment also says paced paths get their horizon from the runtime's measured set_frame_timing feed — same question applies there: is that feed per-frame-accurate under a varying cadence, or also smoothed?

Repro recipe (all on one box, same app, same rate ladder)

Runtime branch builds from #1257 (or any means of producing the cadence regimes):

1. Steady control: stock run — steady 60, smooth.
2. Steady at reduced app rate: DXR_APP_FRAME_DIVISOR=3 on the default hybrid path (slot partition, v2.14.10-20+) — steady 60 (20 app + 40 repaint), verdict "very good".
3. Varying cadence: gate build hz30 adaptive (v2.14.10-16, DXR_AVATAR_PRESENT_HZ=30) — panel oscillates 28–50/s, verdict "stuttery"; or partition v2 on the VK-pinned tier (45–50/s unsteady), same verdict.
4. Move your head laterally at a constant moderate speed while comparing 2 vs 3. Witness lines (DXR_FRAME_WITNESS=5) document the cadence of each run.

The discriminating experiment for the hypothesis: run regime 3 with LEIA_VK_LATENCY_FIXED_US set to the true mean horizon — if stutter persists identically, the error is the per-frame variance (not the estimator's lag), and no scalar setLatency value can be correct; per-weave horizons are needed.

Asks

1. Verify what horizon actually reaches the SR predictor per weave under a varying cadence (adaptive EMA path and the set_frame_timing measured path).
2. If it is smoothed/lagged: provide the actual per-weave horizon — call setLatency (or the timestamped equivalent) before each weave with that weave's real present-to-photon time, which the compositor knows (it owns the schedule; a repaint knows it presents at the next vblank).
3. Vendor question for Leia SR (if per-call setLatency can't keep up or is internally smoothed): does the SR predictor support a per-call prediction timestamp rather than a scalar latency, and is srWeaverSetLatencyInFrames(weaver, 1) (the non-adaptive default) interacting with the adaptive path?

Cross-refs: cadence data and verdicts in DisplayXR/displayxr-runtime#1257 (gate + partition investigation); the steadiness-vs-rate finding is what motivated the slot partition, but why variance is so visible was unexplained until this hypothesis — fixing it would also make variable-cadence modes viable.

[dfattal]

⚠ Partially superseded — see the correction below. The A/B facts here stand; the "two-consumer" interpretation and the split-setter ask do not (the camera/Kooima pose has no bearing on the weaving pose). The evidence-supported mechanism is stale-weave vblanks under varying cadence.

Controlled A/B result — per-weave exact horizon at the weaver alone: no visible improvement, and it narrows this issue to a specific architectural ask.

What was tested

The runtime now computes each weave's forward weave→scanout time from a vsync-locked vblank grid (DXGI frame statistics; measured refresh period, not nominal) and hands it to this plug-in per weave via a new appended DP slot; the plug-in feeds it to the predictor's latency input raw — no EMA, no deadband. This removes the estimator error entirely at the weave consumer: under varying cadence the old smoothed feed carried ±ms of per-weave horizon error, the new feed is exact per weave.

A/B on the breathing-cadence configuration this issue describes (same box, same app, hybrid placement, panel cadence oscillating ~41–55 updates/s in both legs; engagement verified by log in leg B):

• Leg A (forward horizon disabled — the smoothed status-quo feed): stutter as reported.
• Leg B (forward horizon active, exact per weave): "no visible difference both stutter" (viewer-confirmed, watched live back-to-back).
• Steady-cadence sanity (partition D=3): presents 59.9–60.1 flat, weave/repaint pair exact, viewer-confirmed live ("looks good no stutter") — the forward feed causes no regression and stays enabled.

What this eliminates, and what remains

Of the issue's two suspects — "we are not providing the correct latency number" vs "the SR runtime is doing something wrong" — this A/B eliminates the first for the weave path: the number is now exact per weave and the stutter is unchanged.

What remains is structural: one latency scalar serves two consumers with different correct values. The weaver's phase prediction (weave→scanout, ~one refresh) and the app-camera eye positions consumed for the projection (app-render→scanout — several refreshes longer whenever the app runs below panel rate) cannot both be right with a single setter. Under varying cadence the rendered content is therefore still drawn for a mispredicted head position; an exact weave re-derives parallax perfectly over mispredicted pixels, which is consistent with the null result above.

The ask

A way to set the two horizons independently — e.g. a second setter for the eye positions returned to the application/projection path, distinct from the weaver's latency — so the integration can feed each consumer its own exact value (both of which the runtime can now compute forward). With that in place, the per-weave plumbing from this A/B is already the delivery mechanism for the weave half.

🤖 Generated with Claude Code

[dfattal]

Correction to my comment above — the "two-consumer split" framing was wrong and should not drive this issue's ask.

The camera/projection pose has no bearing on the weaving pose: it only determines what content was rendered, while the weaver assigns pixels to views from the tracked eye position at weave time, independently. A stale content pose reads as slight object-space lag, not view-assignment stutter — so the split-setter ask I derived from the A/B null does not follow.

With that channel eliminated, the parsimonious reading of the full dataset is that the varying-cadence stutter is the missed vblanks themselves, not prediction error: at a breathing ~44–55 updates/s, 5–15 vblanks per second present a stale weave — parallax frozen for a vblank or two, then jumping — and no horizon exactness can help a vblank that has no fresh weave behind it. This explains, in one stroke: the A/B null (horizon exactness is orthogonal to unfilled vblanks), why cadence steadiness dominated every visual verdict across this investigation, and why panel-rate weaving (repaint fill / the slot partition) reads crisp even at low app render rates.

Revised status of the issue's two suspects: "wrong latency number at the weaver" — eliminated as the measured cause by the controlled A/B; "SR runtime doing something wrong" — no evidence either; the measured dominant mechanism is stale-weave vblanks, which is a runtime scheduling matter, not a prediction one. Prediction quality remains a real but secondary channel, demoted from suspected cause.

Product conclusion this hardens: keep every vblank carrying a fresh weave (the partition / panel-rate fill path is the fix); cadence gates that leave vblanks unfilled cannot be rescued by better prediction. The per-weave forward-horizon plumbing from the A/B stands on correctness grounds (exact weave-pose target, no regression, viewer-confirmed on the steady config) — see DisplayXR/displayxr-runtime#1263 and #207.

🤖 Generated with Claude Code