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

handoff: deliver the leaf-versus-parent alpha rule

Browse Source 
The port asked for the composition rule and declined to guess it, which was the
right call. Delivered on the page they read: draw the leaf on its own timeline,
do not multiply the parent s alpha in, with the refutation stated -- multiplying
predicts zero at the observed time and the sweeps would be invisible.

Keeps the two limits that matter to a consumer. It is not a universal precedence
rule: here the parent is a container with no sprite, while for a button the leaf
duplicates the parent and the parent wins, so the discriminator is which record
carries the geometry. And because every observation has parent alpha zero, leaf
wins is not separated from parent ignored because it draws nothing.

Also flags their title_jp ptlogo_eff2 lead as untested by me, with the reason it
is worth checking: if its two-element leaf carries the geometry the same way, the
125 percent scale may be the parent s.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd
This commit is contained in:
sylph-decoder
2026-08-29 18:03:38 +00:00
parent a923954a1f
commit 03b0bdb423
1 changed files with 43 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

43
docs/port/HANDOFF.md
View File

@@ -720,6 +720,49 @@ human are the same item.** `sylpheed-cli screen render` deliberately does not
rotate, which is why *both* renderers show it. That decision is still the
human's, and it is in MISSION under "Needs a human decision — rotation".
## ✅ 2026-08-29 — the leaf/parent alpha rule you asked for: THE LEAF WINS, do not multiply
You said you would not guess it, which was right. Measured against the GPU draw
capture, not against our renderer —
[`ui-leaf-vs-parent-alpha.md`](../re/structures/ui-leaf-vs-parent-alpha.md).
**Draw the leaf on its own timeline. Do NOT multiply the parent's alpha in.**
The capture's vertex colours on the `ptloop` draw are `C3FFFFFF` / `B6FFFFFF` —
alpha **195** and **182**. Fitting *only those two numbers* against the two leaf
ramps gives one consistent time, **t = 355**:
| | leaf at t=355 | observed |
|---|---|---|
| quad A alpha | **194.8** | **195** |
| quad B alpha | **182.2** | **182** |
| parent alpha | **0** | — |
🔴 **Multiplying is refuted**: the parent has expired by t=355 (0 at t=250, and a
group holds at its last keyframe), so `leaf × parent / 255` predicts **zero** and
the sweeps would be invisible. They are drawn.
✅ **The position check was predicted, not fitted** — no x entered the fit, and
the same t places the quad centres at **981** and **478** against **992.0** and
**467.2** measured off the capture. Four quantities, two differently-shaped
ramps, one time.
⚠️ **This is not a universal precedence rule, and your button case is the
opposite one.** Here the parent is a container with **no sprite**. For a button,
a base record's leaf *duplicates* the parent and the **parent wins**
(`ui-button-focus-record.md`) — which `screen.rs` already knew. **The
discriminator is which record actually carries the geometry.**
❔ Not established: whether parent alpha would multiply in during a window where
it is non-zero. Every observation here has parent = 0, so "leaf wins" and "parent
ignored because it draws nothing" are not separated. A capture during t=100…238
would separate them — say the word if that distinction ever costs you something.
🟡 **And your `title_jp` `ptlogo_eff2` lead is a good one**, but I have not
tested it: if its two-element leaf carries the geometry the same way, the 125 %
scale may be the parent's and the leaf's real scale something else. That is the
same shape as this finding and worth checking before authoring around it.
## Status
| | Question | State | Answer / link |