# Pre-registration — force the frame rate, and see which quantity moves

**Committed BEFORE the capture.** 2026-09-01. The designed falsification of
[`units-per-frame-is-not-a-constant.md`](units-per-frame-is-not-a-constant.md),
which currently rests on two captures that happened to run at different speeds
rather than on one made to.

---

## The claim under test

> The UI clock advances by **elapsed time**, not by frame count. `units/present`
> is an artefact of the presentation rate; **`units/second ≈ 60` is the
> invariant.**

Evidence so far, all opportunistic:

| capture | presents/s | modal Δα | ⇒ units/present | ⇒ units/s |
|---|---|---|---|---|
| `h3` | 27.2 | **34** | 2.0 | 54.4 |
| boot 1 | 51.4 | **17** | 1.0 | 51.4 |
| boot 2 | 54.8 | **17** | 1.0 | 61.3 / 60.3 (from dwell) |

Two of the three ran at nearly the same rate. **Nobody has yet changed the frame
rate on purpose and watched.**

## The experiment

`--framerate_limit=30`. Xenia's limiter (`graphics_system.cc`) then marks vblank
at 30 Hz instead of 60, halving the ceiling on presents.

## 🔴 The predictions, stated now

| quantity | frame-based clock | **time-based clock (my claim)** |
|---|---|---|
| presents/s | ~27 | ~27 |
| **modal Δα per present** | **17, unchanged** | **34, doubled** |
| **units/s** | **~30, halved** | **~60, unchanged** |
| publisher splash dwell | ~8.5 s, doubled | **~4.2 s, unchanged** |
| developer splash dwell | ~7.0 s | **~3.5 s, unchanged** |

**These diverge on every row but the first.** I accept the time-based reading only
if the modal step lands in **30–38** *and* the dwell stays within 10 % of 4.2 /
3.5 s. If the step stays at 17 and the dwell doubles, **my claim is refuted and
`units/s` is 30 at this limit**, which would mean the clock is frame-based after
all and the whole rate question reopens with the port's 60 unsupported again.

⚠️ Note which way the risk runs: a doubled step is the result that *confirms* me,
and it is also what a frame-based clock would show if the limiter did not actually
take effect. **So the control is the present rate itself** — if presents/s does
not fall to ~27, the flag did nothing and neither prediction is tested. That is
the first number I will read, before the step.

## Second control

The splash **quad geometry** must be unchanged — same eight NDC rects. If the
rects move, something other than the frame rate changed between runs and the
comparison is not clean.

## What this cannot settle

Whether the console's rate is 60. Everything here is measured under Canary's
limiter; the claim being tested is only that the clock is *time*-driven and that
its rate is ~60 units/s **as this emulator runs it**. A time-based clock is
immune to dropped frames, which is why that is worth something — but it is not
the console.