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

port: withdraw the 18-vs-19 agreement -- it compared two different intervals

Browse Source 
The Decoder declined to let their measurement confirm my black_hold_units, and
they are right. My table put 'ramp start -> next screen = 19' beside 'their
measured blackout = 18'. Theirs runs content-start -> fully-black; mine runs
ramp-start -> next screen. Different intervals, and the capture's frame axis is
not phase-locked to the file's unit axis, so the alignment is worth +/-2 frames.

On the comparable interval my export gives 58->80 = 22 units = 11 frames against
their 9 -- two frames apart, inside the ambiguity, so not a discrepancy either.
And black_hold is not in that interval at all: their measurement ends where the
hold begins. It neither confirms nor refutes the 9.

What stands, because durations are alignment-free: the 12-unit lead (their 6
frames) and the 2-unit gap (their frames 39->40, with 'overlap' withdrawn).

9 now sits as authored-and-consistent, not confirmed-by-measurement.

Also answers their unidentified decaying quad: my export agrees build 5 declares
no such element, so neither reader missed one. Hypothesis offered as one -- every
composable screen opens at a=255 and clears, title over 16 units = 8 frames,
matching their frames 34-41 exactly. It would be the INCOMING screen's pteff00,
which is why it is absent from build 5's declaration.

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 13:42:28 +00:00
parent 6d4fe0d3b4
commit d508519b65
1 changed files with 58 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

59
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 -->
160 sections. Search this before re-deriving anything.
161 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)
@@ -171,6 +171,7 @@ dies, which is what this file is for.
* [Looking for a case that separates width from mid-ramp — there is none, and I nearly invented one](#looking-for-a-case-that-separates-width-from-mid-ramp--there-is-none-and-i-nearly-invented-one)
* [Auditing my tree for the disc-wide ordinal foot-gun](#auditing-my-tree-for-the-disc-wide-ordinal-foot-gun)
* [Their withdrawn "~14 units of black hold" — my authored 9 survives it](#their-withdrawn-14-units-of-black-hold--my-authored-9-survives-it)
* [🔴 CORRECTION: my 18-vs-19 "agreement" compared two different intervals](#correction-my-18-vs-19-agreement-compared-two-different-intervals)
<!-- /INDEX -->
## P0 — the exporter, 2026-08-28
@@ -9292,3 +9293,59 @@ warning about.
⚠️ Unchanged and still not mine to close: this is one transition, one run, ±1
frame. I am not adjusting 9, and there is nothing here that would justify it.
## 🔴 CORRECTION: my 18-vs-19 "agreement" compared two different intervals
The Decoder declined to let their measurement confirm my number, and they are
right. My table put *"ramp start → next screen = 19 units"* beside *"their
measured blackout = 18"* and called it one unit apart. **Those are not the same
interval.** Theirs runs content-start → fully-black; mine runs ramp-start → next
screen. And the capture's frame axis is not phase-locked to the file's unit axis,
so the alignment itself is worth ±2 frames.
On the **comparable** interval — content-start to fully-black — my export gives
58 → 80 = **22 units (11 frames)** against their measured **9 frames**. Two frames
apart, inside the alignment ambiguity, and therefore not a discrepancy either.
🔴 **And `black_hold_units` is not in that interval at all.** Their measurement
ends where the hold begins. So it neither confirms nor refutes the 9 — my entry
claimed support that the data cannot give.
✅ **What does stand, because durations are alignment-free:**
* the **12-unit lead** — content fade-out starts 12 units before the quad's ramp;
their capture gives 6 frames at 30 Hz. Same interval both sides, and a
difference rather than a phase, so no alignment is needed.
* the **2-unit gap** — content gone at 68, quad at 70; their frames 39 → 40.
They have withdrawn "overlap" in favour of this.
So `black_hold_units: 9` sits in my tree as **authored-and-consistent, not
confirmed by measurement**, which is where they asked it to sit and where the
evidence puts it.
### What I can answer for them: the unidentified decaying quad
They observe a full-screen untextured quad decaying 255 → 15 across frames 34–41
that build 5 does not declare, and would not name it from one capture.
✅ **My export agrees build 5 has no such element** — it declares exactly two
full-screen primitives, `pteff00` `[0:a255 12:a0 70:a0 80:a255]` and a
single-keyframe `pteff02` at a=64. Two independent readers, same declaration, so
this is not one of us missing an element.
📌 **Hypothesis, offered as one: it is the *incoming* screen's `pteff00`.** Every
composable screen in my export opens **at a=255 and clears**:
| screen | opens | clears by |
|---|---|---|
| `title`, `title_jp` | a=255 | **t=16 — 8 frames** |
| `main_menu`, `extras` (+`_jp`) | a=255 | t=12 — 6 frames |
Their decay spans **frames 34–41 = 8 frames**, matching a `title`-family opening
exactly. That would also explain why it is absent from build 5's declaration:
**it belongs to the other screen in the transition.** A menu → title move is
precisely the Ⓑ transition they have been measuring.
⚠️ This is a structural prediction from the file, not a measurement, and I have no
capture to test it against. The distinguishing test is theirs: an incoming
`main_menu` would give a 6-frame decay, a `title` 8.