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

port: the re-opened rest() pair reaches nothing we draw, and 60 units/s is authored now

Browse Source 
Two things, and both are about a label being wrong rather than a value.

1. THE rest() PAIR IS MOOT FOR THIS PORT, and that is measured rather than
waited on. R1 re-opened both legs, 8 further claims died with the
⟨render-vs-capture⟩ instrument, and ScreenView.settle_time() uses rest.t -- so
this port has been sitting on a question with no instrument behind either side.

An element reaches the plateau-less fallback exactly when no two consecutive
keyframes are identical. Census over all sixteen screens at every nesting depth:
FIVE elements, three distinct -- palogo_sqex_eff, palogo_anima_eff, ptlogo_eff3,
plus two region twins.

And every one of them is transparent where its rest pose is read:

  publisher_logo   t=140         not drawn: palogo_sqex_eff  (transparent)
  developer_logos  t=117         not drawn: palogo_anima_eff (transparent)
  title_jp         --pose=rest   not drawn: ptlogo_eff3      (transparent)

So no rest() rule -- plateau-plus-dwell, `last`, `maxalpha` or `lastall` -- can
change any pixel this port draws. That is why the splash rows score 0.01 %
against their captures while resting on a heuristic nobody can currently defend:
it is not load-bearing there.

🔴 And the brief's "the two splashes are the ONLY screens reaching that fallback"
is narrowly refuted -- title_jp reaches it too, via ptlogo_eff3. Stated as a
measurement of the CURRENT export: the record-layout fix re-timed keyframes
corpus-wide and a plateau is exactly what that could create or destroy, so this
does not say the claim was wrong when written.

⚠️ It does NOT rehabilitate rest.t, still wrong for transients like
ptlogo_back2eff1 whose rest.t=54 is a two-frame flash's PEAK. That is a plateau
case, not a fallback case, and nothing here touches it.

2. keyframe_units_per_second RECLASSIFIED measured -> authored. The value does not
move; the label was false. The Decoder withdrew their guest-frame-rate finding
the same day they published it, and this file carried `kind: measured` on its
strength. Three routes now disagree -- withdrawn movie cadence 60, vblank ~120,
title-plate-delay ~56 -- and at most one is right.

60 is kept, and not as a coin toss: the one leg of this file's own reasoning that
never touched a frame count still brackets it. The transition quad is declared
black for 12 units and the capture measured 0.14-0.30 s, i.e. 40-86 units/s. 60
sits inside; 120 does not; ~56 is 7 % away and inside the same bracket.

🔴 audit-kinds caught my first attempt at this, DANGLING: I cited
guest-frame-rate-WITHDRAWN.md, which is on their branch and not in my checkout --
citing a document I cannot read. The check doing exactly its job. The withdrawal
is now named in prose and labelled as coming from their message.

📌 Their method note is worth more than the number and is recorded in the file:
their pre-registration named three ways the ruler could lie and guarded two; the
third occurred, and a PERFECT 1.0000 is precisely what it produces. A clean result
on an instrument whose key assumption is unguarded is not confirmation -- the
cleanness may be the failure mode's own signature. Same family as this port's
non-inverting latch check, which passed for the wrong reason until its control
failed.

Not settled: finding 3 still has no surviving cause; the ~1.0-1.2 menu residual
against the additive-capable reference; pgloading_loop5's own residual; and the
allowance still waits on its grep trigger.

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:13:57 +00:00
parent 94e44b5ba4
commit 3df042f10f
3 changed files with 133 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

1
docs/port/BLOCKED.md
View File

@@ -174,6 +174,7 @@ submitted per frame.
| **H5** | ✅ **CLOSED, and now confirmed from the other side too.** `pgloading_loop5` is additive, which is why `build_12`/`build_15` differed and `build_00`/`build_01` did not — the latter never draw it. With the reference taught the additive blend (`formats-pin-2026-09-01b`) **`build_00`/`build_01` go DIFFERS → OK** (`over3` 3422 → 0) and `build_12`/`build_15` fall 0.0772 → 0.0463. | ⚠️ They do **not** return to their pre-change 0.0368, so `pgloading_loop5` carries a small residual of its own beyond the blend — recorded, not chased. 📌 The Decoder nearly reported my H5 claim as a contradiction because `loop5` is not a sprite: it is an **element**, `pgloading_loop5.rat`, resolving to sprite `pgloading_ring.t32`. **The element/sprite name split is a trap for any census keyed by sprite name** — worth knowing before writing one. |
| **H6** | ✅ **CLOSED — and my counter-example FAILED, which is the honest outcome.** The blend map is deleted; the exporter emits `blend_additive` per element from `T8aD +0x04` bit `0x02`. | ❌ I reported `pteff10` as a possible counter-example. **It is not** — the oracle measures it additive on `main_menu` in all three menu sessions, every frame, and my premise was a stale coverage table sitting upstream of its own correction. **I treated a summary as the log.** The 10.88 → 13.02 is characterised rather than excused: max difference **32 levels** over 36 % of the frame, zero pixels past 60 — broad and shallow, which is what moves an **area-weighted** RMSE 20 % while being invisible to an eye. Not excluded from the metric, deliberately: the reason to exclude turned out to be false. See [`blend-decoded-adoption.md`](blend-decoded-adoption.md). |
| **H7** | ✅ **CLOSED 2026-09-01 — WITHDRAWN BY THE DECODER, same day.** `splash-rate-withdrawn.md` / `1e7343e`: *"WITHDRAW 'the unit rate is per-GamePart' — it was the emulator's frame rate"*, and the section carrying it is struck. §1 of `splash-declared-vs-captured.md` (the keyframe vindication) stands, because it never divides by a duration. | The port never moved, so nothing had to be undone. The refutation is kept in [`splash-rate-contradiction.md`](splash-rate-contradiction.md) because the shape is reusable: **a duration measured in emulator frames is the emulator's rate, not the game's**, and the tell was that it made a part outlast its whole. `keyframe_units_per_second` remains **60**, now unchallenged on the splashes. |
| **H8** | 🟢 **NOT AN ASK — a bound, recorded so nobody spends an iteration on it.** The re-opened `rest()` pair **cannot change a single pixel this port draws.** Only **five elements in the whole export** reach the plateau-less fallback — `palogo_sqex_eff`, `palogo_anima_eff` and `ptlogo_eff3` (plus two region twins) — and **every one is fully transparent** at the instant anything reads its rest pose. | 🔴 **And the brief's claim that the two splashes are the ONLY screens reaching it is narrowly refuted: `title_jp` does too.** Stated as a measurement of the current export — the record-layout fix re-timed keyframes corpus-wide and a plateau is exactly what that could create or destroy, so this does not say the claim was wrong when written. ⚠️ It does **not** rehabilitate `rest.t`, which is still wrong for transients like `ptlogo_back2eff1` — that is a *plateau* case, untouched. See [`rest-fallback-reaches-nothing.md`](rest-fallback-reaches-nothing.md). |
## Still open — these block work

87
docs/port/rest-fallback-reaches-nothing.md Normal file
View File

@@ -0,0 +1,87 @@
# The re-opened `rest()` pair cannot change a single pixel this port draws
**Status:** ✅ **measured, and it bounds a question rather than answering it.**
Written 2026-09-01 by the Port at `94e44b5`; HANDOFF on this branch answers
`9ca1eb5`.
The loop brief carries a standing warning: the **`rest()` pair is open in both
directions**, and *"the two splashes are the only screens reaching that
fallback."* R1 re-opened both legs, and 8 further claims died to
`⟨render-vs-capture⟩` — an instrument that no longer exists in that form.
`ScreenView.settle_time()` uses `rest.t`, so this port has been sitting on a
question with no instrument behind either leg. **It turns out not to matter, and
that is worth establishing rather than waiting on.**
## What reaches the fallback
`Element::rest()` takes the longest **plateau** — a run of consecutive identical
keyframes — and falls back to the longest dwell when there is none. So an element
reaches the fallback exactly when no two consecutive keyframes are identical.
Census over all sixteen exported screens, at every nesting depth:
| screen | elements reaching the fallback |
|---|---|
| `publisher_logo` (and `_r`) | `palogo_sqex_eff` |
| `developer_logos` (and `_r`) | `palogo_anima_eff` |
| **`title_jp`** | **`ptlogo_eff3`** |
**Five elements in the whole export**, and only three distinct ones.
## 🔴 The brief's claim is narrowly refuted
*"The two splashes are the **only** screens reaching that fallback"* — `title_jp`
reaches it too, through `ptlogo_eff3`.
⚠️ Stated as a measurement of the **current** export and nothing more. That
sentence may have been true when written: the record-layout fix re-timed
keyframes across the corpus, and a plateau is exactly the kind of thing it could
create or destroy. This does not say the claim was wrong when made; it says it is
not true now.
## And every one of them is invisible where it is read
The fallback only matters if the element it picks a pose for is actually drawn.
Asked of the port directly, at each screen's own settled instant:
```
publisher_logo t=140 drew 2 not drawn: palogo_sqex_eff (transparent at t=140)
developer_logos t=117 drew 4 not drawn: palogo_anima_eff (transparent at t=117)
title_jp --pose=rest drew 23 not drawn: ptlogo_eff3 (transparent at rest)
```
**Every element that reaches the `rest()` fallback is fully transparent at the
instant anything reads its rest pose.**
> So no `rest()` rule — the current plateau-plus-dwell, `last`, `maxalpha` or
> `lastall` — can change any pixel this port draws. The pair is open, and for the
> port it is **moot**.
That is why the splash rows score 0.01 % against their captures while resting on
a heuristic nobody can currently defend: the heuristic is not load-bearing there.
## Why this was worth an iteration rather than a wait
The three elements are the **pre-blurred companion glows** and one title sparkle
— transients that exist to be seen briefly and then leave. An element with no
plateau is, almost by definition, one that never holds still, and a screen's
settled instant is chosen to be where things are holding still. The two
conditions are close to mutually exclusive, which is why the intersection is
empty and why it was worth checking rather than assuming either way.
⚠️ **This does not rehabilitate `rest.t`.** It is still the wrong answer for
transients — `ptlogo_back2eff1` is a two-frame flash whose `rest.t = 54` is the
flash *peak*, and `rest()` would leave five of those burning at once on the
title. That is a **plateau** case, not a fallback case, and it is untouched by
anything here.
## What this does not claim
* That the `rest()` pair is settled. It is open, and this page does not touch it.
* That `rest.t` is right. `settle_time()` still takes the maximum over elements,
and what that means for *when the boot advances* is a separate question — a
screen still plays to `exit_time()` afterwards, so the dwell is governed by
that, not by `rest.t`. **Measured for the drawn picture; argued for the dwell.**
* Anything about the other 7 claims R1 re-opened against
`⟨render-vs-capture⟩`. Not mine to re-derive.