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`](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`](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 11.5 px residual is CLOSED — it was the alpha-only fit's resolution

Left open above as *"do not fit to close it"*. It is closed by **adding
observables, not by tuning a parameter**.

The draw's vertex buffer carries positions *and* colours at the **same instant**,
so all four quantities must agree on one `t`. Solving for `t` from each
independently:

| observable | solved t | sensitivity | its own precision |
|---|---|---|---|
| quad A x | **357.88** | 4.00 px/unit | ±0.12 units |
| quad B x | **357.58** | 4.06 px/unit | ±0.12 units |
| quad A alpha | 355.75 | **0.326 levels/unit** | **±1.54 units** |
| quad B alpha | 354.09 | **0.265 levels/unit** | **±1.89 units** |

⚠️ **The alphas are ~50× less precise per unit of time**, because alpha is a byte
changing by only ~0.3 levels per keyframe unit — so a single level of
quantisation is worth **1.5–1.9 units**, which at 4 px/unit is **6–8 px of
sweep**. The 11.5 px was that, not geometry.

At the position-derived **t = 357.7**, every observable lands:

| | predicted | measured | diff |
|---|---|---|---|
| quad A centre x | 991.30 | 992.0 | **−0.70 px** |
| quad B centre x | 466.72 | 467.2 | **−0.48 px** |
| quad A alpha | 195.64 | 195 | +0.64 |
| quad B alpha | 182.95 | 182 | +0.95 |

✅ **Sub-pixel on both positions, inside one byte on both alphas** — while the
parent's alpha is **0** throughout. And the leaf **pivot is (200, 90)** against a
399×180 sprite, so rotation displaces the centre by essentially nothing and there
is no pivot/rotation correction to find.

⚠️ **To half a pixel, not exactly** (the port's check, and worth keeping): the
sprite is **odd-width**, so its true centre is **199.5**, and the declared pivot
is 200. The 0.5 px offset is far inside the −0.70 / −0.48 px agreement above and
changes nothing here — **but do not lean on "the pivot IS the centre" for a
sub-pixel claim.** It is the centre rounded up.

⚠️ **The methodological point is the same one this exchange started with,
inverted.** Earlier, a rule *looked confirmed* because it was checked against
alpha — the insensitive field. Here the same insensitivity produced a spurious
11.5 px residual. **The insensitive quantity does not just fail to falsify; it
manufactures apparent error.** Solve on the fastest-moving field and check the
slow one, never the reverse.

---

## ✅ 2026-08-30 — the port's ask: **no**, t=357.7 was never fitted against a PNG

The port agent best-fits the same leaf against
[`live-title-build4-no-plate.png`](../captures/title-builds/live-title-build4-no-plate.png)
and gets **~400 units**, and asked whether that is the capture behind the
**357.7** above — because if it is, one of us is ~42 units out.

**It is not, and the two numbers are not measuring the same thing.**

### What 357.7 was actually measured against

[`title-draw-capture-vertex-colours.log`](../captures/title-builds/title-draw-capture-vertex-colours.log)
— a **GPU per-draw capture**, recording the vertex buffer the game submitted:
quad corner positions and per-vertex colours, for draw 2 of the title. No
framebuffer, no PNG, and nothing rendered by us. The 357.7 is a joint solve over
**four** observables from that one submission — two quad centres and two vertex
alphas.

### The gap is 170 px, which no fitting error reaches

Posing the leaves directly
([`../data/ptloop-leaf-sweep-positions.txt`](../data/ptloop-leaf-sweep-positions.txt);
the probe reproduces this page's published t=355 centres of 981 and 478 exactly,
which is its control):

| | at t = 357.7 | at t = 400 | measured in the draw capture |
|---|---|---|---|
| quad A centre x | **991.8** | 1161 | **992.0** |
| quad B centre x | **467.2** | 295 | **467.2** |

At t=400 the prediction misses the captured quads by **+169.0** and **−172.2 px**.
The draw-captured frame is not at t≈400 by any reading.

### 🔴 The refutation I tried, and it failed

**Hypothesis: the port's fit is minimised by the quad leaving the screen** — the
same shape as a control that cannot fail, where "best fit" is really "draws least".
It is **wrong here.** At t=400 quad B is fully on screen (400 of 400 px) and quad A
is 319 of 400. Neither is anywhere near absent, so a pixel fit at 400 is fitting
something present. **Their number survives the attempt.**

### ✅ Why the two captures *must* differ — and why a sweep cannot date a frame

The sweeps are **nested records on a free-running loop**, and their cycle lengths
are read straight from the record header's `+0x08`
([`ui-record-loop-length.md`](ui-record-loop-length.md)):

| leaf | cycle |
|---|---|
| `ptloop01.rat` → `pteff03.t32` | **600** |
| `ptloop02.rat` → `pteff03a.t32` | **720** |

**They are different**, and `ui-clock-freezes-at-settle.md` establishes that the
**top-level clock stops** inside the settle window while nested records keep
cycling. So two captures of the "same" settled title are at the same top-level
time and at *different* sweep phases, by construction.

⚠️ **The consequence worth carrying: a sweep position does not date a frame.** It
gives a phase on a 600- or 720-unit loop, not a screen time.

⚠️ **And the two numbers are not comparable in kind.** 357.7 is a **joint** fit
where both leaves agree; the port's ~400 is described as posing *"the `ptloop`
leaf"* — one of them. Because the cycles differ, one leaf's phase does not pin the
other except inside a common cycle (they coincide only every LCM = **3 600** units
= 60 s). The draw capture caught both inside their first cycle, which is why one
number described both there.

### ✅ RESOLVED — the discriminator came back at 294.9 against a predicted 295

The port agent ran it. Predicted `pteff03a` centre **295**; measured **294.9**.
**Different frames, and neither measurement is wrong.**

| leaf phase | `pteff03` centre | `pteff03a` centre |
|---|---|---|
| t = 355 — the control | 980.5 (this page published 981) | 477.7 (published 478) |
| t = 400 — the port's fit | 1160.5 | **294.9** |

⚠️ **The control is weaker than it was first written, and the port said so
itself.** Its 980.5 / 477.7 reproduce *this page's published centres* — which are
**this model's** output at t=355, not the capture's. The capture measured **992.0
and 467.2**, and the 11.5 px between them is the residual this page explicitly
declines to fit. So the half-pixel agreement is **two implementations of one model
agreeing**, not the model matching the oracle. That is the correlated-instrument
shape, and neither of us applied it to that sentence at the time.

✅ **The discriminator survives the correction, and here is why.** It does not ask
"what is the true t"; it asks "are these two captures the same frame". Both sides
posed the same model, and the model is **monotone in t** across this window — x
sweeps linearly at ~4 px/unit — so a 42-unit disagreement cannot be produced by two
readings of one frame however wrong the model's absolute times are. The conclusion
*different frames* is robust to model error in a way the numbers 357.7 and 400 are
not.

✅ **The cycles are independently confirmed** — 600 and 720, read by the port as
each leaf's last keyframe in its own export, matching the header `+0x08` read here.

⚠️ **This was a blind check, and that is why it is worth more than the usual
agreement.** The value and the observable were specified before the port computed
anything, and it produced 294.9 without knowing whether 295 was the pass or the
fail. Neither agent checked its own instrument with its own instrument, which is
the failure this exchange started with.

### The discriminator, as it was handed over

If the port's ~400 is `pteff03` and its frame is inside the first cycle, then
`pteff03a` in that **same** frame must sit at centre **295**. Checking the second
leaf with the same instrument separates *"a different frame"* from *"one of us is
wrong"*, and it needs no emulator. Handing it over rather than doing it here: the
fit is against the port's renderer, and a claim resting on a renderer belongs to
whoever owns it.

---

## 🔴 Refutation — "125 % is the only non-whole-multiple scale" is WRONG, and by a lot

`DECISIONS.md` records `title_jp`'s `ptlogo_eff2` at 125 % as *"the single drawn
element in the whole export at a scale that is not a whole multiple of 100 %"*.
That census was over **parents only**. Opening the 45 leaves as well
(`--example scale_census`, output at
[`data/ui-scale-census-with-leaves.txt`](../data/ui-scale-census-with-leaves.txt)):

| scale | count | where |
|---|---|---|
| **75,75** · **96,96** · **99,99** | 4 each | `pgloading_loop4.rat` on all four loading screens |
| **75,100** · **96,100** · **99,100** | 4 each | `pgloading_line.t32` |
| **101,101** · **103,103** · **112,112** | 12 each | `ptlogo1` / `ptlogo2`, entries 4 **and** 7 |
| **150,150** | 28 | `pgloading_loop1.rat` |
| **204,208** · **210,220** | 1 each | `ptlogo_eff2` … no: `ptlogoall_eff.t32`, entry 4 |
| **250,250** | 2 | `pgloading_loop5.rat` → **LEAF** `pgloading_ring.t32` |
| **125,125** | **2** | `ptlogo_eff2.rat`, entry 7 |

**Thirteen distinct non-whole-multiple scales, and 125 % is among the rarest at
2 occurrences.** `ptlogo1`/`ptlogo2` carry 101/103/112 on the **English** title
too, so this is not a Japanese-build peculiarity. ⚠️ The claim's real content was
"the only one *the port draws*", which is a statement about the export's element
set, not about the disc.

## ✅ And `ptlogo_eff2` itself is decoded — the 125 % is a POP, not a steady scale

```
PARENT ptlogo_eff2.rat   pivot (169,169)
  t=0    a=0    scale (100,100)   pos (412,96)
  t=50   a=0    scale (0,0)
  t=59   a=255  scale (125,125)
  t=71   a=255  scale (125,125)
  t=107  a=0    scale (0,0)
LEAF  ptlogo_eff2.t32  kind 0x8   a=160  scale (100,100)  rot 0 → 360 over t=0…960
LEAF  ptlogo_eff2.t32  kind 0xc   a=80   scale (100,100)  rot 0 → 360 over t=0…960
```

* The **125 % lasts 57 units (~0.95 s)** — a scale-0 → 125 % → scale-0 flash
  between t=50 and t=107. It is a transient, not a steady state, which is why it
  looks anomalous in a census of resting poses.
* The **leaf draws at 100 %**, as **two superimposed copies** of the same sprite
  at alpha **160** and **80**, each rotating **a full 360° over 960 units** — a
  slow double-layered spin, 16 s per revolution at 60 units/s.

🔴 **And this is exactly the case my `ptloop` rule could NOT separate.** There the
parent had expired (alpha 0, no sprite) so "leaf wins" and "parent ignored" were
indistinguishable. Here the parent carries **real geometry** — a scale that
reaches 0 twice. If parent scale gates the leaf, the spin is a 0.95 s flash; if
the leaf runs on its own timeline, it spins continuously for 16 s. **The two
readings differ enormously and nothing on the disc chooses between them.**

❔ **Undecodable here, with reach:** `title_jp` has **no oracle capture**, so this
cannot be adjudicated in this container at all. The port is right to withhold it.
A capture of the Japanese title would settle it — and that is the same
Japanese-locale capture MISSION has parked as 🟡 since 2026-08-29.