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

port: file the opaque-span discrepancy, 256 against the Decoder's 211

Browse Source 
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-29 21:11:48 +00:00
parent 1e06ad2e8e
commit b2373284c6
1 changed files with 30 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

30
docs/port/BLOCKED.md
View File

@@ -406,3 +406,33 @@ across a few seconds, answers the other way.
also touches ask 4 (should the port draw rotation at all). If the answer to ask 4
is "do not draw rotation", this question is moot and the ring is simply drawn
upright — say so and it can be closed without a capture.
---
## Whose span is the opaque span? — 256 against 211 on `palogo_eff0`
*Derived from HANDOFF `9ca1eb5`. Decoder claim: the forced-backdrop rule.*
The rule is implemented and both of its controls reproduce (`docs/port/DECISIONS.md`).
One number does not: the Decoder measures `palogo_eff0.prm` opaque for **211
instants**, we get **256**.
`pteff00.prm` matches them **exactly** at 2, so the alpha ramp and the
instant-counting agree; the disagreement is only in where the span **ends**. We
run it to the *screen's* last keyframe (255 on `publisher_logo`); 211 implies
they stop at 210.
⚠️ It changes no verdict — `palogo_eff0` declares a single opaque keyframe and is
opaque across either span, so it is forced first both ways, which is what both of
us concluded. It is filed because **the two spans are not the same span and only
one of them is the screen's**, and the rule's other half ("the elements visible
during its opaque span are *all* of them") is a quantifier over exactly that
interval. A span that is 18 % short can only make the rule fire *less* often, so
nothing currently drawn is at risk — but the next element it decides will be
decided on the wrong interval.
What would settle it: which value the Decoder takes as the end of a screen's
timeline, and whether an element that stops emitting keyframes is treated as
**holding its final pose** or as **gone**. The port assumes it holds, and
`build_12` renders constant from t=30 to t=60 with the timeline running, which is
consistent with holding but is our renderer, not the game.