Sylpheed/docs/re/f6-unit3-sweep-track-fits.md

F6 unit 3 — the sweep's position fits the declared track: origin at leaf t=0, both endpoints within ~2 px

Status: ✅ measured ⟨capture⟩ ×1. 2026-09-02.

Question: where does the sweep's own clock start, and how fast does it run? Look at: its pixel x against the declared leaf track. Pass = the ends land on the declared endpoints; fail = they do not. Not covered: whether parent alpha multiplies in (that is unit 2, still 🟡); F5.

---

Why position, and not alpha — the port's point, adopted

Three exchanges went on alpha: a bound, a refutation, a downgrade, over 14 usable samples of 1754. Alpha is 8-bit, quantised and non-monotone, and a grouping slip in its tail is indistinguishable from signal. The position travels 2 160 px monotonically in the same capture and cannot fail those ways. The port made that argument and built tools/port/fit-trajectory for it; this is the same measurement, run on my side against the raw stream.

The measurement

pteff03's declared leaf track is linear at 4.000 px/unit: x = −639 @ t=0, −39 @ t=150, 1521 @ t=540.

The capture's sweep, converted from NDC centre to pixel left edge:

first segment   frames 746 … 1913     x  −641.1  →  +1522.1
declared        t = 0 … 540           x  −639    →  +1521
                                      Δ  −2.1 px      +1.1 px

Both endpoints land within ~2 px on a 2 160 px travel — 0.1 %. Two independent checks, not one fitted parameter.

📌 A single wrap at frame 1914 (x jumps back > 500 px) confirms the declared 600-unit loop, and it falls after the segment measured, so the segment is clean.

What it answers

• Clock origin: the leaf's t = 0 is its first drawn frame. The −2.1 px start says the game does not carry the leaf forward from the title's clock. ✅ This confirms the port's own correction — they had earlier attributed ~135 units of earliness to the leaf clock starting at title t=0, and withdrew it on two relayed numbers; the full series says their withdrawal was right.
• Rate here: 540 declared units in 1 167 presents = 0.463 units/present.

⚠️ The rate is the weak half and I am flagging it rather than burying it. It is in presents, on one emulator run, and it does not match the 1 unit/present the splash work established. Either the leaf runs on a slower clock than the element timeline, or one of the two is not what I think it is. The origin does not depend on it — that rests on the endpoints alone.

🔴 A linear fit across the whole capture FAILS, and that is the useful part

Fitting x = a + b·frame over all 1 754 samples gives max residual 1 108 px on 1 402 px of travel — 79 %. Read alone that says "the model is wrong". It is not: the trajectory wraps, and a straight line through a sawtooth is meaningless.

A fit that had not been checked for residual would have reported a slope and a plausible-looking origin from that same data. The port's insistence that their tool's selftest must reject a wrong-shape series is exactly this failure, and it is why I segmented before fitting rather than after.

Reach

⟨capture⟩ ×1, one boot, one segment, one element. The identification is now sound — unit 2's correction established both size-keys are pteff03 and it travels left-to-right, which the declared track predicts and the measurement matches at both ends. pteff03a does not appear in this capture and is untested.