Decide: success gates and the measurement protocol #11

New Issue

2026-08-11T15:41:39Z

lars commented

2026-08-11 15:41:39 +00:00

Question

Fix the numbers that count as pass, and the protocol that produces them, before anyone runs a session.

Settle:

Gates for render frame rate, pose-to-photon latency, alignment residual, and positioning error — each with pass / investigate / fail bands and a named fallback for fail.
The measurement protocol two coding devs will actually follow: what gets logged, in what format, by whom, at which points. This substitutes for the dedicated measurer the team does not have.
How rendered-vs-real comparison is done repeatably — marking positions and facing directions physically, rather than eyeballing.
Where results land so they are comparable across sessions.
A written caveat on every gate stating what the office room does and does not prove.

Part of the wayfinder map #1.

## Question Fix the numbers that count as pass, and the protocol that produces them, before anyone runs a session. Settle: - **Gates** for render frame rate, pose-to-photon latency, alignment residual, and positioning error — each with pass / investigate / fail bands and a named fallback for fail. - The **measurement protocol** two coding devs will actually follow: what gets logged, in what format, by whom, at which points. This substitutes for the dedicated measurer the team does not have. - How rendered-vs-real comparison is done repeatably — marking positions and facing directions physically, rather than eyeballing. - Where results land so they are comparable across sessions. - A written caveat on every gate stating what the office room does and does not prove. --- Part of the wayfinder map #1.

lars added this to the Wayfinder: RN prototyping spec milestone 2026-08-11 15:41:39 +00:00

lars added the wayfinder:grilling label 2026-08-11 15:41:39 +00:00

lars added a new dependency 2026-08-11 15:42:13 +00:00

#2 Research: on-device visual relocalization against a gaussian splat

lars added a new dependency 2026-08-11 15:42:13 +00:00

#3 Research: WebGL2 splat viewer performance inside iOS WKWebView

lars added a new dependency 2026-08-11 15:42:13 +00:00

#13 Write the Session 0 spec (positioning bake-off)

lars added a new dependency 2026-08-11 15:42:14 +00:00

#14 Write the Session 1 spec (pose to splat rendering)

lars referenced this issue

2026-08-11 15:50:36 +00:00

Configure and verify the three TG-BT5-IN beacons #9

lars commented

2026-08-11 15:54:11 +00:00

Input from #3 — two of your four gates cannot be set from literature.

There is no published splat frame-rate measurement inside WKWebView, anywhere. So ≥30fps and <100ms pose-to-photon are aspirations, not calibrated thresholds, and writing them as pass/fail bands would dress up a guess as a gate.

Consequences for this ticket:

Measure before you legislate. #3's advice: a timestamp-echo latency probe is an afternoon's work and needs no splat at all. Run it, then set the latency band from what the bridge actually does.
Add a memory gate, which #3 can ground: budget ~1.5M gaussians and ≤300–400MB in the WebContent process. Note that the load-time transient is what triggers jetsam, not steady-state usage — so the gate must be measured during load, not after.
The 60Hz rAF cap in WKWebView works in our favour — it bounds the render loop, so a 30fps target sits at half the ceiling rather than at it.
Frame rate is best set as a first-measurement-becomes-the-baseline gate rather than a number chosen in advance.

**Input from #3 — two of your four gates cannot be set from literature.** There is **no published splat frame-rate measurement inside WKWebView**, anywhere. So `≥30fps` and `<100ms pose-to-photon` are aspirations, not calibrated thresholds, and writing them as pass/fail bands would dress up a guess as a gate. Consequences for this ticket: - **Measure before you legislate.** #3's advice: a timestamp-echo latency probe is an afternoon's work and needs no splat at all. Run it, then set the latency band from what the bridge actually does. - **Add a memory gate**, which #3 *can* ground: budget ~1.5M gaussians and ≤300–400MB in the WebContent process. Note that the **load-time transient** is what triggers jetsam, not steady-state usage — so the gate must be measured during load, not after. - **The 60Hz rAF cap in WKWebView works in our favour** — it bounds the render loop, so a 30fps target sits at half the ceiling rather than at it. - Frame rate is best set as a *first-measurement-becomes-the-baseline* gate rather than a number chosen in advance.

lars referenced this issue

2026-08-11 15:54:11 +00:00

Write the Session 1 spec (pose to splat rendering) #14

lars referenced this issue

2026-08-11 15:55:43 +00:00

Measure the RN → WebView pose-bridge latency #16

lars added a new dependency 2026-08-11 15:55:43 +00:00

#16 Measure the RN → WebView pose-bridge latency

lars referenced this issue

2026-08-11 16:02:01 +00:00

Research: WebGL2 splat viewer performance inside iOS WKWebView #3

lars commented

2026-08-11 16:08:09 +00:00

Add a sustained/thermal gate — peak frame rate is the wrong measurement.

Mobile-GS (ICLR 2026) measured 127 → 74 FPS thermal collapse at 0.83 W on a Snapdragon 8 Gen 3. For calibration on the good side, PlayCanvas WebGPU renders 4M splats at 42 FPS on a 2021 iPhone 13 Pro Max.

So a 60-second benchmark will report a number the app never sustains. Navigation sessions are minutes long, held in a warm hand, with the screen bright and the camera running for VIO — close to worst-case thermally.

Concretely:

Gate on steady-state frame rate after ≥5 minutes of continuous running, not on a fresh-start reading.
Record the decay curve, not just start and end — where it plateaus is the design number.
Log device thermal state alongside, so a failed gate can be attributed to thermals rather than to the renderer.
Combine with the earlier note on measuring frame-interval distribution rather than mean fps: thermal throttling and compositor jitter are different failures and both hide behind a mean.

**Add a sustained/thermal gate — peak frame rate is the wrong measurement.** Mobile-GS (ICLR 2026) measured **127 → 74 FPS thermal collapse at 0.83 W** on a Snapdragon 8 Gen 3. For calibration on the good side, PlayCanvas WebGPU renders **4M splats at 42 FPS on a 2021 iPhone 13 Pro Max**. So a 60-second benchmark will report a number the app never sustains. Navigation sessions are minutes long, held in a warm hand, with the screen bright and the camera running for VIO — close to worst-case thermally. Concretely: - Gate on **steady-state frame rate after ≥5 minutes of continuous running**, not on a fresh-start reading. - Record the **decay curve**, not just start and end — where it plateaus is the design number. - Log device thermal state alongside, so a failed gate can be attributed to thermals rather than to the renderer. - Combine with the earlier note on measuring **frame-interval distribution rather than mean fps**: thermal throttling and compositor jitter are different failures and both hide behind a mean.

Sign in to join this conversation.