Sylpheed/docs/port/rest-fallback-reaches-nothing.md

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.