From 6213c92ce2d8173a7ac81c066fc2374d41e2f4bd Mon Sep 17 00:00:00 2001 From: Sylpheed port agent Date: Wed, 2 Sep 2026 18:45:10 +0000 Subject: [PATCH] port: kill the variant-link explanation for the extra sweep The Decoder's candidate 2 -- 'a focus/variant link means only one of the pair is active' -- is answerable from the export and the answer is no. It looked strong: ptloop01 carries opt_link=ptloop02.rat, it is the only linked element on the title, the field comes straight from el.focus_link, and the port never reads it. But surveying opt_link across the whole export splits it in two: *f.rat targets are variant-only, everything else is a top-level element drawn in its own right. And the second population chains across kinds -- on main_menu, ptloop01 -> ptloop02 -> ptbtn01 -> ptbtn01f. A light sweep points at a BUTTON, which a variant selector cannot do. So opt_link is a chain pointer that lands on the focus variant when the element happens to be a button, which is why it was exported as focus_link. Candidate eliminated; the port ignoring it is not what draws the extra sweep. Surviving smaller finding: focus_link carries two different things and is named after one. Nothing depends on it today. --- docs/port/f6-what-starts-the-sweep.md | 63 +++++++++++++++++++++++++++ 1 file changed, 63 insertions(+) diff --git a/docs/port/f6-what-starts-the-sweep.md b/docs/port/f6-what-starts-the-sweep.md index ce6fee97..63235543 100644 --- a/docs/port/f6-what-starts-the-sweep.md +++ b/docs/port/f6-what-starts-the-sweep.md @@ -320,3 +320,66 @@ candidate for *"the glow starts too early"*. **Not covered:** the start time of `pteff03` itself, which is still open; and the parent-alpha question, still 🟡. + +--- + +# ❌ Unit d — the "variant link" explanation, raised and killed in one pass + +The Decoder's second candidate for why the game submits `ptloop01` and not +`ptloop02` was *"a focus/variant link means only one of the pair is ever +active"*. **That is answerable from the export, and the answer is no.** + +## What looked like a smoking gun + +`ptloop01` carries **`opt_link = "ptloop02.rat"`**, `ptloop02` carries none, and +it is the only linked element on the title screen. The field is exported straight +from `el.focus_link` (`crates/sylpheed-export/src/screen.rs:622`), and +**`port/scripts/` never reads it.** An ignored variant link would have explained +the extra sweep exactly. + +## ❌ And it is not a variant link + +Surveying `opt_link` across the whole export splits it into two populations: + +| target | example | is the target also a top-level element? | +|---|---|---| +| `*f.rat` | `ptbtn00 → ptbtn00f` | **no** — variant only | +| everything else | `ptloop01 → ptloop02` | **yes** — both are drawn | + +And the second population **chains across unrelated element kinds**. On +`main_menu`: + +``` +index 3 ptloop01 -> ptloop02.rat +index 4 ptloop02 -> ptbtn01.rat +index 10 ptbtn01 -> ptbtn01f.rat +``` + +**A light sweep points at a button.** A variant selector cannot do that, so +`opt_link` is a chain pointer that happens to land on the focus variant when the +element is a button — which is why it was exported under the name `focus_link`. + +> So the field does not select between `ptloop01` and `ptloop02`, and the port +> ignoring it is not what draws the extra sweep. **Candidate eliminated.** + +## The smaller finding that survives + +**`focus_link` is carrying two different things** and the exporter names it after +only one of them. The `*f` population is a variant; the rest is a chain. Nothing +depends on this today — the port reads neither — but the name asserts a meaning +the data does not support, and the next person to reach for it will reach for the +wrong one. Worth renaming when something actually needs it; not worth a +re-export on its own. + +## Where that leaves F6 + +The lead is unchanged and unexplained: **the port draws `pteff03a`, the game's +capture never does** — now confirmed by an exhaustive scan of every tall quad in +1..2499 rather than a filtered subset. One of the two candidate causes is now +eliminated from the export side, which leaves the Decoder's first: a zero-alpha +skip suppressing the opening frames. ⚠️ That one does not obviously survive +either — it would explain `pteff03a`'s *opening* frames, not its whole run, and +its leaf reaches α=128 well inside the captured window. + +**Nothing is deleted and the renderer is unchanged**, pending one five-second +human look: one streak, or two?