fabi/Sylpheed
1
0
Fork 0
Code Issues 9 Pull Requests Actions Packages Projects Releases Wiki Activity

port: withdraw my "no hold" finding -- the port holds, and 60 is now positively supported

Browse Source 
The Decoder withdrew 120 and returned to 60, which the port never left. Nothing
has to be undone. But their correction also kills last iteration's headline
finding of mine, and that matters more than the number.

🔴 WITHDRAWN: "the port has no hold" and "two errors that cancel".

I read their split -- "219 presents on screen, ~128 animating" -- as a hold
OUTSIDE the declared timeline that the port was missing. It is a split WITHIN it.
The publisher ramps 0-30, HOLDS 30-235 (205 units, 80.4 % of the screen) and
fades 235-255, and this port plays all three.

Measured rather than read. Frozen samples of the logo region:

  t=0.25 s (15 u)  0.390957   mid-ramp
  t=1.00 s (60 u)  0.405488
  t=2.00 s (120 u) 0.405488
  t=3.00 s (180 u) 0.405488
  t=3.80 s (228 u) 0.405488   identical to six decimals across 168 units
  t=4.20 s (252 u) 0.038142   in the exit fade

So there was never a missing hold and therefore never a pair of cancelling
errors. authored/timing.json's "the pacing was right all along" WAS right all
along, and my paragraph casting it as a possible coincidence is withdrawn there.

⚠️ The failure was not a mis-measurement. I took a two-part split from someone
else's instrument and assumed its boundary sat where my own model put it.
Presents are not units, and "animating vs holding" in presents does not decompose
the same way as "ramp vs hold" in declared units. That is a new failure shape for
this corpus and it is worth the name.

✅ AND THE DWELL FIGURES ARE NOW POSITIVE EVIDENCE, not survivors. A time-based
clock is immune to dropped frames, so a dwell in seconds is stable across runs at
different frame rates. The port's own splash dwell across a 4.0x change in its
rendering rate -- work done two iterations ago for an unrelated reason:

  17.3 fps -> 4.28 s     19.6 -> 4.26     25.0 -> 4.27     69.4 -> 4.26

a 0.5 % spread, putting 255 units at 59.6-59.9 units/s every time.

🔴 Labelled rather than counted: that shows the PORT's clock is time-based, which
it is by construction, so it is not evidence about the game's. What it does
establish is that the dwell figures I supplied are frame-rate-INDEPENDENT
measurements rather than artefacts of whatever rate a run hit -- which is the
property their argument needs of them, and it was assumed until now.

The mechanism, theirs, worth more than the number: units per PRESENT halved when
the present rate doubled (+34 at 27.2 presents/s, +17 at 51.4) while units per
SECOND did not move (54.4 vs 51.4). "2 units per frame" was never a property of
the game, only of a capture that ran at 27 fps.

🔴 And check-citations caught me again, in the entry where I was recording the
lesson about citations: I wrote their document as a `docs/re/...md` path that does
not resolve here. The check does not care about the disclaimer next to it, which
is correct. Named without a path now.

Finding 3 is OPEN AGAIN with no surviving named cause. Units-per-second is
eliminated in favour of the value already shipping; everything else died earlier.
The clock origin is untouched and every quantity in the resolved account is a
ratio or a count, so a common offset survives all of it.

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-01 19:38:19 +00:00
parent c24ea3ba0e
commit c6b3256574
2 changed files with 138 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files

51
authored/timing.json
View File

@@ -197,7 +197,25 @@
"at 120 the publisher splash runs 2.13 s and the developer 1.75 s, against three",
"cold boots measuring 4.30/4.60/4.37 and 3.51/3.50/3.37. 120 and the dwell corpus",
"cannot both be right in wall-clock seconds -- the same collision that killed the",
"35 units/s proposal from the other direction."
"35 units/s proposal from the other direction.",
"",
"✅ 2026-09-01 (final position of the day) — 120 IS WITHDRAWN BY ITS AUTHOR AND 60",
"IS POSITIVELY SUPPORTED. The port never moved, so nothing has to be undone.",
"",
"The mechanism is worth more than the number: `units per present` HALVED when the",
"present rate doubled (Δα +34 at 27.2 presents/s, +17 at 51.4) while units per",
"second did not move (54.4 vs 51.4). The UI clock advances by elapsed TIME, not",
"by frame count -- so '2 units per frame' was never a property of the game, only",
"of a capture that happened to run at 27 fps. The 120 was 2 units/present x 60",
"presents/s, and the first factor is not a constant, so the product was not a",
"rate.",
"",
"Their write-up is `units-per-frame-is-not-a-constant.md`, under docs/re/ on",
"their branch. 🔴 NOT IN THIS CHECKOUT, so it is named WITHOUT a resolvable",
"path -- `tools/port/check-citations` flagged the first version of this very",
"paragraph as DANGLING, in the entry where I was recording the lesson about",
"dangling citations. The check does not care about a disclaimer, which is",
"correct: a path that does not resolve does not resolve."
],
"kind": "authored",
"source": "docs/re/ui-keyframe-time-unit.md, docs/port/HANDOFF.md",
@@ -287,7 +305,36 @@
"📌 And when it does move it is TWO changes, not one: the constant, and a hold",
"measured as (screen presents - animation presents). It must NOT be inferred from",
"the total, because the total is precisely the quantity that cannot distinguish",
"the two errors. docs/port/units-per-second-switch-readiness.md."
"the two errors. docs/port/units-per-second-switch-readiness.md.",
"",
"✅ 2026-09-01 (later still) — THE PARAGRAPH ABOVE IS WITHDRAWN. 'The pacing was",
"right all along' WAS right all along.",
"",
"I claimed the dwell agreement might be a coincidence of two cancelling errors --",
"a 2x-slow animation plus a missing hold. There is no missing hold. I misread a",
"presents split from the Decoder's instrument ('219 on screen, ~128 animating')",
"as a hold OUTSIDE the declared timeline. It is a split WITHIN it: the publisher",
"ramps 0-30, HOLDS 30-235 (205 units, 80.4 % of the screen) and fades 235-255,",
"and this port plays all three.",
"",
"Measured rather than read -- frozen samples of the logo region across the",
"publisher splash: 0.405488 at t=60, 120, 180 and 228 units, identical to six",
"decimals across 168 units, with 0.391 at t=15 (mid-ramp) and 0.038 at t=252",
"(in the exit fade). The hold is there and it is played.",
"",
"⚠️ The failure was not a mis-measurement. I took a two-part split from someone",
"else's instrument and assumed its boundary sat where my own model put it.",
"Presents are not units, and 'animating vs holding' in presents does not",
"decompose the same way as 'ramp vs hold' in declared units.",
"",
"AND THE DWELL FIGURES HERE ARE NOW POSITIVE EVIDENCE, not merely survivors. A",
"time-based clock is immune to dropped frames, so a dwell measured in seconds is",
"stable across runs at different frame rates. This port's own splash dwell across",
"a 4.0x change in its rendering rate: 4.28 s at 17.3 fps, 4.26 at 19.6, 4.27 at",
"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."
],
"dwell_kind": "measured",
"looping_focus_records": {

92
docs/port/units-per-second-switch-readiness.md
View File

@@ -1,8 +1,10 @@
# If 120 units/s is right, the switch is one constant — audited, and pre-registered
**Status:** ✅ **audit done, change NOT made.** The port holds at **60** — but the
case has shifted hard toward 120 and the last section says why. 🔴 **My falsifier
below was malformed and is conceded.** Written
**Status:** ✅ **RESOLVED — 60 is right and is now positively supported.** 120 is
withdrawn by its author. The port never moved, so nothing has to be undone.
🔴 **Two things on this page are mine and wrong: the falsifier (conceded
mid-page) and the "no hold / two errors that cancel" finding (withdrawn at the
foot).** Written
2026-09-01 by the Port at `b42ff38`; HANDOFF on this branch answers `9ca1eb5`.
The Decoder now measures **120 units/s** with a content-hash experiment whose
@@ -193,3 +195,87 @@ When that lands, the switch is **two** changes, not one: the constant, and a hol
whose length is `screen_presents − animation_presents` and which must be
**measured, not inferred from the total** — because the total is exactly the
quantity that cannot distinguish the two errors.
---
# 🔴 WITHDRAWN: "the port has no hold" and "two errors that cancel"
Both were mine, both were last iteration's headline, and both are wrong.
## What I misread
The Decoder gave a split — *"219 presents on screen, ~128 animating"* — and I
read it as a hold **outside** the declared timeline, which the port would then be
missing. **It is a split *within* the timeline.** The declared group is ramp +
hold + fade, and the hold is the largest part of it:
```
publisher palogo_sqex: 0:a=0 15:a=0 30:a=255 235:a=255 239:232 251:32 255:0
ramp 0→30 = 30 units
HOLD 30→235 = 205 units ← 80.4 % of the screen
fade 235→255 = 20 units
```
## The port plays it. Measured, not read
Frozen samples across the publisher splash, logo region:
| t | units | region mean |
|---|---|---|
| 0.25 s | 15 | 0.390957 |
| 1.00 s | 60 | **0.405488** |
| 2.00 s | 120 | **0.405488** |
| 3.00 s | 180 | **0.405488** |
| 3.80 s | 228 | **0.405488** |
| 4.20 s | 252 | 0.038142 |
**Identical to six decimals across 168 units.** The port holds, for 80 % of the
screen, exactly as declared.
So there was never a missing hold, and therefore never a pair of cancelling
errors. **`authored/timing.json`'s "the pacing was right all along" was right all
along**, and my paragraph casting it as a possible coincidence is withdrawn there
too.
⚠️ The failure is worth naming because it is not the usual one: I did not
mis-measure anything. **I took a two-part split from someone else's instrument and
assumed the boundary was where my own model put it.** Presents are not units, and
"animating vs holding" in presents does not decompose the same way as "ramp vs
hold" in declared units.
# ✅ And the port's own data is an independent leg for the time-based clock
The Decoder's mechanism: `units/present` halved when the present rate doubled
while `units/second` did not move, so the UI clock advances by elapsed **time**,
not by frame count — and *"2 units per frame"* was a property of a 27 fps capture
rather than of the game.
**The frame-rate work of two iterations ago tests exactly that, and I did not
notice at the time.** The same splash, measured across a 4× change in the port's
own rendering rate:
| | frame rate | dwell | implied units/s |
|---|---|---|---|
| llvmpipe | 17.3 fps | 4.28 s | 59.6 |
| llvmpipe | 19.6 fps | 4.26 s | 59.9 |
| llvmpipe | 25.0 fps | 4.27 s | 59.7 |
| **GPU** | **69.4 fps** | **4.26 s** | **59.9** |
**Frame rate varies 4.0×; the dwell varies by 0.5 %.** That is the signature of a
time-based clock, and it puts the rate at 59.6–59.9 every time.
🔴 **This is a weaker leg than it looks and I am labelling it rather than
counting it.** It shows *the port's* clock is time-based — which it is by
construction, `time_units += delta * units_per_second` — so it cannot be evidence
about the game's. What it does show is that the **dwell figures I supplied are
frame-rate-independent measurements**, not artefacts of whatever rate a run
happened to hit. That is the property their argument needs of them, and it is now
established from this side rather than assumed.
# Where finding 3 stands
**Open, with no surviving named cause.** Units-per-second is eliminated in favour
of the value the port already ships; every other candidate died earlier. The
clock origin remains untouched, and every quantity in the resolved account is a
ratio or a count, so a common offset survives all of it.