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

port: refute the 8.5% splash-dwell systematic -- it is the span, not the clock

Browse Source 
They challenged the dwell agreement: declared spans 240 u and 195 u at 60 u/s give
4.000 and 3.250 s against six cold boots whose ratios all exceed 1, mean 1.085,
implying 54-56 units/s. And that 240 units at 60 should give 4.000 where I report
4.28.

The port does not play 240 units. Their 240 is the visible span, the logo
element's 15->255. The port plays the whole group from t=0, and my export gives
the full spans as 255 and 210 units -- 4.250 and 3.500 s. My 4.28 and 3.58 are
those plus transition overhead.

Recomputed against what the port plays, the ratios become 1.011, 1.083, 1.028,
1.002, 1.001, 0.962 -- mean 1.0145 with one of six below unity, against their mean
1.085 with none below. The systematic largely dissolves.

Their practical consequence does not follow either: the gap is 0.174 s, not 0.42,
and on developer_logos the port runs 0.041 s LONGER than the oracle mean, the
opposite sign.

Fourth instance of the same family after pivot-as-extent, centre-track-as-bbox and
cycle-length-as-motion-duration: a visible span read as a played span -- and the
first where the misread number was mine to supply and I had never stated which
span the port plays.

What survives: publisher still runs long in two of three boots against the full
group. Much weaker than 8.5%, thin at three boots, and no support for changing
keyframe_units_per_second.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01N7FiFFFwbvG2uxdcEh8HyF
This commit is contained in:
Sylpheed port agent
2026-08-30 17:25:35 +00:00
parent 0583b15fba
commit ccd6fe7b48
1 changed files with 48 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

49
docs/port/DECISIONS.md
View File

@@ -9,7 +9,7 @@ dies, which is what this file is for.
<!-- INDEX: generated by tools/port/index-decisions -- do not hand-edit -->
190 sections. Search this before re-deriving anything.
191 sections. Search this before re-deriving anything.
* [P0 — the exporter, 2026-08-28](#p0--the-exporter-2026-08-28)
* [P1 — Godot draws the screen, 2026-08-28](#p1--godot-draws-the-screen-2026-08-28)
@@ -201,6 +201,7 @@ dies, which is what this file is for.
* [The leaf thread, closed — one export value verified against the game, one self-check abandoned](#the-leaf-thread-closed--one-export-value-verified-against-the-game-one-self-check-abandoned)
* [Delivering the phase term where the numbers are, not where I found them](#delivering-the-phase-term-where-the-numbers-are-not-where-i-found-them)
* [The boot verified as a *sequence*, not just at its endpoint](#the-boot-verified-as-a-sequence-not-just-at-its-endpoint)
* [Refuting the "8.5 % systematic" in the splash dwells — it is the span, not the clock](#refuting-the-85--systematic-in-the-splash-dwells--it-is-the-span-not-the-clock)
<!-- /INDEX -->
## P0 — the exporter, 2026-08-28
@@ -10777,3 +10778,49 @@ route. And the 144.76 s video is unexamined beyond playing.
"has now been wrong in two opposite directions". **That is at least the fourth
time this session the answer was already written down** — but this time reading it
cost one command, because I looked before concluding rather than after.
## Refuting the "8.5 % systematic" in the splash dwells — it is the span, not the clock
They challenged my dwell agreement: declared spans **240 u** and **195 u** at
Q1's 60 u/s give 4.000 s and 3.250 s, against six cold-boot measurements whose
ratios all exceed 1 (mean **1.085**), implying 54–56 units/s rather than 60. And
pointedly: *"240 units at exactly 60 should give you 4.000 and you're reporting
4.28."*
🔴 **The port does not play 240 units.** Their 240 is the *visible* span — the logo
element's 15→255. The port plays the **whole group from t=0**, and my export gives
the full spans as **255** and **210** units, i.e. **4.250 s** and **3.500 s**. My
observed 4.28 and 3.58 are those plus a frame or two of transition overhead, not
an 8.5 % overshoot of anything.
Recomputed against the interval the port actually plays:
| | their ratios (vs 240/195) | recomputed (vs 255/210) |
|---|---|---|
| publisher | 1.074, 1.151, 1.093 | 1.011, 1.083, **1.028** |
| developer | 1.079, 1.078, 1.036 | 1.002, 1.001, **0.962** |
| mean | **1.085** | **1.0145** |
| below unity | 0 of 6 | **1 of 6** |
✅ **The systematic largely dissolves.** A mean deviation of 1.5 % with one
measurement below unity is not a clock running at 54 u/s; it is six numbers
scattered around a declared duration.
⚠️ **And the practical consequence they drew does not follow.** *"A port playing
240 units at 60 u/s shows the publisher splash 0.42 s less than the game."* The
port plays 255 units, so the gap is **0.174 s** — and on `developer_logos` the
port is **0.041 s longer** than the oracle mean, the opposite sign. There is no
direction to correct in.
📌 **Same family as the three we have already catalogued** — a pivot anchor read
as a drawn extent, a centre track read as a bounding box, a cycle length read as a
motion duration. Here: **a visible span read as a played span.** Fourth instance,
and the first where the misread number was mine to supply and I had not stated
which span my port plays.
🟡 **What survives, and I would not want it lost in the refutation.** Against the
full group the publisher screen still runs long in two of three boots (1.011,
1.083, 1.028) while the developer screen sits at 1.002, 1.001, 0.962. That is a
much weaker signal than 8.5 % and it is not nothing. Three boots per screen is
thin — their own caveat — and it does not support a change to
`keyframe_units_per_second`, which stays where Q1 put it.