Sylpheed/docs/re/structures/ui-leaf-vs-parent-alpha.md

✅ A nested .rat leaf animates on its OWN timeline — the parent's alpha does not multiply in

Status: ✅ DECODED, against a GPU draw capture rather than our renderer. Answers the port's question: it emits both a parent record and its nested leaf, each with its own alpha ramp over a different span, and would not draw the leaf without knowing the composition rule.

The question

For the title's light sweeps, parent and leaf disagree about everything:

	ptloop01 parent	its leaf pteff03.t32
alpha	0 → 255 over t=70…100, held to 238, → 0 at 250	255 → 128 at t=150 → 255 at 540
scale	(100, 100)	(100, 600)
rotation	0	+30°
x	fixed 441	−639 → −39 → 1521

ptloop02's leaf pteff03a.t32 is the mirror: (100, 800), −45°, x sweeping 1721 → 1111 → −839, alpha 0 → 128 → 255.

The oracle

The per-draw capture records vertex colours, and on the title's ptloop draw (draw 2) they are C3FFFFFF and B6FFFFFF — alpha 195 and 182, not 255. So the composed alpha the game actually submitted is observable.

The measurement

Fitting only the two alphas to the two leaf ramps gives a single consistent time, t = 355:

	leaf value at t=355	observed
quad A alpha	194.8	195
quad B alpha	182.2	182
parent alpha (both)	0	—

🔴 Multiplying the ramps is refuted. The parent has expired by t=355 (it returns to 0 at t=250 and a group holds at its last keyframe), so leaf × parent / 255 predicts 0 for both quads — the sweeps would be invisible. They are drawn, at 195 and 182.

✅ And the position check was PREDICTED, not fitted. Nothing about x entered the fit; the same t=355 then places the quads from the leaves' own sweeps:

	from the leaf at t=355	measured off the capture
quad A centre x	981	992.0
quad B centre x	478	467.2

Within ~11 px, on 400-px-wide quads travelling 1 560 and 1 950 px. Four quantities — two alphas and two positions, from two differently-shaped ramps — all agree on one time.

The rule

A leaf carrying geometry animates on its own timeline. The parent's alpha does not gate it. For these records the parent is a container: it has no sprite, and its keyframes describe nothing that is drawn.

⚠️ Reach, and it is not a universal rule about leaves. This is one draw, one capture, one element pair, and it is specifically the case where the parent carries no geometry. The opposite case is already recorded: for a button, a base record's leaf duplicates the parent and the parent wins (ui-button-focus-record.md). So the discriminator is which record actually carries the geometry, not a fixed precedence.

❔ What is not established: whether the parent alpha would multiply in during a window where it is non-zero. Every observation here has parent = 0, so "the leaf wins" and "the parent is ignored because it has nothing to draw" are not separated. A capture during t=100…238 would separate them.

---

🔴 The port's x = −324 is the OLD keyframe association, applied to leaves

Implementing the rule above, the port reported the leaf's top-left at x ≈ −324 at t=355 — off-screen left — against 781 (centre 980.5) here. Both cannot be right, and the disagreement is not about rotation or pivots.

Their stated pairing is "t=150 at x=−639, t=540 at x=−39". On the disc the leaf reads:

pose x	its time	the time it would take under the OLD association
−639	0	150
−39	150	540
1521	540	600
1521	600	—

Their pairing is the second column. Each pose is taking the next pose's time — which is exactly the association ui-keyframe-record-layout.md refuted and HANDOFF carries a red banner about: a keyframe's time comes before its pose. Feeding their pairing into the same interpolation reproduces −324 to the digit.

✅ With the corrected association, t=355 gives top-left 781, and centre 980.5 for a 399-wide sprite — against 992.0 measured off the capture.

⚠️ So this is the same defect as the top-level one, in the leaf path. The top-level parser was corrected on 2026-08-29; a leaf is read by parse_build on a sub-slice, so anything reading leaves through a separate path can still carry the old association. That the alphas nonetheless matched is the trap: alpha at t=355 is inside a long segment where a one-keyframe shift barely moves it, while x is sweeping 1 560 px over the same span and the shift is glaring. A rule can look confirmed on the insensitive quantity and be wrong on the sensitive one.

❔ The residual 11.5 px between 980.5 and 992.0 is not explained by this and is left open — a rotation about a pivot rather than the centre would displace by about that much, and nothing here measures it.