Sylpheed/docs/re/clock-is-frame-based-one-unit-per-present.md

✅ The UI clock is FRAME-based: 1 unit per present, verified by a forced frame rate

Status: ✅ measured, by a designed test that REFUTED my own previous claim. 2026-09-01. Instrument: ⟨capture⟩ ×3, one of them at a deliberately altered presentation rate. Answered against time-based-clock-preregistration.md, committed before the run. Data: data/forced-framerate-test.txt.

---

The test, and it went against me

I claimed the clock was time-based and that units/second ≈ 60 was the invariant. I predicted that halving the frame rate would double the alpha step and leave the dwell unchanged. I ran --framerate_limit=30:

	frame-based	time-based (my claim)	measured
presents/s	~27	~27	28.4
modal Δα per present	17 unchanged	34 doubled	17 — unchanged
units/s	~30 halved	~60 unchanged	30.2 / 30.3 — halved
publisher dwell	~8.5 s	~4.2 s	8.450 s — doubled
developer dwell	~7.0 s	~3.5 s	6.923 s — doubled

Every discriminating row went to the frame-based column. My claim is refuted.

Both controls passed first, as pre-registered:

• Control 1, read before the step: the limiter took effect — 28.4 presents per host-second against 51–55 before, and the interval histogram's mass moved from one 60 Hz vblank to two (422 of 468). Had this failed, neither prediction would have been tested.
• Control 2: all 8/8 splash quad rects identical to the reference set, so nothing but the frame rate differs between runs.

What is actually true

The UI clock advances exactly 1 unit per presented frame. The step is 17 on every quad in every capture — at 28.4, 51.4 and 54.8 presents per second. 255 × 1 / 15 = 17 with the declared T = 15.

So units/second = presents/second, and the seconds are whatever the frame rate makes them. The dwell in seconds is not a property of the game.

The conclusion for the port is unchanged, and now properly grounded

The guest, unconstrained, presents once per 60 Hz vblank — measured before the limiter was applied (one vblank 71.7 %, two 24.6 %), and confirmed by this run moving cleanly to two vblanks when told to. One unit per present at 60 presents per second is 60 units/s.

The port's 60 is right. It was right when I first said so for a bad reason, right when I withdrew it, right when I replaced it with 120, and right now — the difference is that the mechanism is finally tested rather than inferred.

🔴 What this withdraws, including of my own

• units-per-frame-is-not-a-constant.md is WRONG in its central claim and is superseded by this page. Units per frame is a constant; it is 1.
• My "dwell is stable across runs because a time-based clock is immune to dropped frames" was a real prediction and it failed — the dwell doubled. The four-run agreement at 4.2 / 3.5 s that I read as evidence for a time-based clock was just four runs at similar frame rates.
• ⚠️ h3-units-per-frame-measured.md's +34 is now the anomaly, not the rule. It reports 34 per label at 27.2 labels/s; this capture reports 17 per present at 28.4 presents/s. Both cannot be presents. The likeliest reading is that an h3 label is not one present, and until that is checked its "2 units per frame" should not be used. I have not checked it, and I am not asserting it is wrong — only that it and this disagree at nearly the same rate, which one of them must explain.

The methodological point, since this is the fourth reversal today

Three of my four positions on this number came from inference over a measured quantity; this one came from changing an input and watching what moved. The opportunistic comparison — two captures that happened to differ — pointed exactly the wrong way, because I had no control on what else differed between them. The designed test cost one capture and settled it against my own expectation.

📌 And the pre-registration did its job in the only way that really counts: it made the refuting result unmissable. Had I not written down "34, doubled" first, "17" would have been easy to read as confirmation of something.

Reach

⟨capture⟩ ×3 at two deliberately different rates, one machine, English locale. The invariance of the step is the load-bearing part and now rests on a manipulation rather than a coincidence. ❔ Whether the console presents at 60 is still an inference from the vblank cadence — a short one, since a 360 vblanks at 60 Hz, but an inference.