port: withdraw "a third independent route", and measure the dwell residual I had only inferred

Two corrections to my own file, one from the Decoder and one from a GPU.

1. "60 NOW STANDS ON A THIRD INDEPENDENT ROUTE" IS WITHDRAWN. I recorded it last
iteration and challenged it in the same breath -- three routes to one number are
weaker than they look if they share an upstream assumption -- but I wrote the
claim down first and the caveat second. The Decoder audited it and agreed: route
B needs "the guest presents 60x/s", from the vblank histogram UNDER Xenia's 60 Hz
limiter; route C needs "the vblank is 60 Hz", that limiter's cvar; route D is a
wall-clock duration that lands on 60 only because the vblank is 60 Hz. One
witness in three coats.

 What survives is conditional and better, established by MANIPULATION rather
than agreement -- forcing 30 Hz gave 30.2 units/s, 60 Hz gives 59.8/61.3:

    units per second = THE DISPLAY REFRESH RATE.

It becomes "60" only through a fact this corpus has never measured: an Xbox 360
outputs 60 Hz. A hardware specification -- solid, and belonging CITED as a spec
rather than folded in as a third measurement.

📌 The conditional form justifies this port's construction rather than excusing
it. "units/s = refresh rate" says what to do on hardware that is NOT 60 Hz, which
is exactly why a time-based clock at a fixed 60 units/s is right where a
frame-based one would drift. `kind` stays `authored`, and the reason is now
sharper: the measurement is of a RELATIONSHIP, and the constant that closes it
comes from a datasheet.

2. THE +1.2 / +1.6 UNIT DWELL RESIDUAL WAS FRAME GRANULARITY -- measured now,
not inferred. I attributed it to the exit check's granularity without testing it.
The GPU makes it testable: same boot, same declared groups, 65-66 fps instead of
17-25.

Pre-registered: shrink roughly with the frame rate, so <=0.5 units at 65 fps.

  publisher  4.27 / 4.26 / 4.27  mean 4.253 s  residual +0.20 units
  developer  3.50 / 3.52 / 3.50  mean 3.500 s  residual +0.00 units

From +1.2 and +1.6 to +0.20 and +0.00. The prediction held. ⚠️ It also means the
4.270 / 3.527 quoted elsewhere carry a rendering-rate term; 4.250 / 3.500 is what
the port hits when the renderer keeps up.

Housekeeping: Xvfb did not survive the restart again -- the exact failure the
check-all display guard was written for, now with a second occurrence. Restored;
the port runs on the GPU at 65-66 fps.

Not settled: findings 3 and 4, both still without a surviving named cause; the
clock origin, where their FRAMES=9000 capture reached 96 % of the movie and
FRAMES=11000 should clear it; the ~1.0-1.2 menu residual.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018AHUQvXGyNcKonSEWsgWcX
This commit is contained in:
Sylpheed port agent
2026-09-02 15:10:40 +00:00
parent 907b2b5487
commit 59cf6d8608

View File

@@ -298,7 +298,37 @@
"real-time pace through a drop, per-present slows. This port is time-based, so",
"it matches per-vblank exactly and would run marginally ahead of per-present",
"during drops only. On a console presenting every vblank the two coincide, and",
"the screens in question are a handful of quads."
"the screens in question are a handful of quads.",
"",
"🔴 2026-09-02 (later) — 'A THIRD INDEPENDENT ROUTE' IS WITHDRAWN BY ITS AUTHOR.",
"The paragraph above says 60 now stands three ways. It does not, and I recorded",
"the claim before challenging it hard enough.",
"",
"I raised that three routes to one number are weaker than they look if they share",
"an upstream assumption -- vblank rate, present rate and declared dwell are not",
"obviously independent. The Decoder audited it and agreed: route B needs 'the",
"guest presents 60x/s', which comes from the vblank histogram UNDER XENIA'S 60 Hz",
"LIMITER; route C needs 'the vblank is 60 Hz', which is that limiter's cvar; route",
"D is a wall-clock duration that lands on 60 only BECAUSE the vblank is 60 Hz.",
"All three reduce to one upstream fact: the display refreshes 60 times a second",
"on that emulator. One witness in three coats.",
"",
"✅ WHAT SURVIVES IS CONDITIONAL AND BETTER, and it is established by MANIPULATION",
"rather than agreement -- forcing 30 Hz gave 30.2 units/s, 60 Hz gives 59.8/61.3:",
"",
" units per second = THE DISPLAY REFRESH RATE.",
"",
"It becomes '60' only through a fact this corpus has never measured: an Xbox 360",
"outputs 60 Hz. That is a hardware specification. It is solid, and it belongs",
"CITED as a spec rather than folded in as a third measurement.",
"",
"📌 And the conditional form is the one that justifies this port's construction",
"rather than excusing it. 'units/s = refresh rate' says what to do on hardware",
"that is NOT 60 Hz, which is exactly why a time-based clock at a fixed 60 units/s",
"is right and a frame-based one would drift. `kind` stays `authored`: nothing",
"here promotes it, and the reason it is not `measured` is now sharper -- the",
"measurement is of a RELATIONSHIP, and the constant that closes it comes from a",
"datasheet."
],
"kind": "authored",
"source": "docs/re/ui-keyframe-time-unit.md, docs/port/HANDOFF.md",
@@ -417,7 +447,27 @@
"25.0, 4.26 at 69.4 -- a 0.5 % spread, putting 255 units at 59.6-59.9 units/s",
"every time. That establishes these dwells are frame-rate-independent",
"MEASUREMENTS rather than artefacts of whatever rate a run hit, which is the",
"property the Decoder's argument needs of them."
"property the Decoder's argument needs of them.",
"",
"✅ 2026-09-02 — THE +1.2 / +1.6 UNIT RESIDUAL WAS FRAME GRANULARITY, and that is",
"now measured rather than inferred.",
"",
"The dwells were recorded as 4.270 s and 3.527 s against declared 4.250 and 3.500",
"-- residuals of +1.2 and +1.6 units -- and I attributed them to the granularity",
"of the exit check without testing it. A hardware GPU makes that testable: same",
"boot, same declared groups, three runs at 65-66 fps instead of 17-25.",
"",
"Pre-registered: if the residual is frame granularity it should shrink roughly",
"with the frame rate, so <= 0.5 units at 65 fps. Measured:",
"",
" publisher 4.27 / 4.26 / 4.27 mean 4.253 s residual +0.20 units",
" developer 3.50 / 3.52 / 3.50 mean 3.500 s residual +0.00 units",
"",
"From +1.2 and +1.6 down to +0.20 and +0.00. The prediction held and the",
"attribution is no longer an assumption. ⚠️ It also means the figures quoted",
"elsewhere in this corpus as 4.270 / 3.527 carry a rendering-rate term; the",
"declared values are what the port actually targets and 4.250 / 3.500 is what it",
"hits when the renderer keeps up."
],
"dwell_kind": "measured",
"looping_focus_records": {