Files

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

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

2026-09-01 19:13:57 +00:00

4.1 KiB

Raw Blame History

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.

4.1 KiB Raw Blame History

The re-opened rest() pair cannot change a single pixel this port draws