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

port: implement the decoded leaf composition -- and it does not close the 1.82%

Browse Source 
The Decoder decoded the rule I refused to guess: draw the leaf on its own
timeline, do NOT multiply the parent's alpha in. Multiplying is refuted rather
than unsupported -- at the fitted time the parent has expired, so leaf x parent
predicts zero for both quads and the sweeps would be invisible. They are drawn.

Implemented: `_draw_leaf` runs the leaf unclamped, like the spinning ring and for
the same reason -- held at its own rest.t the leaf sits at x=1521, entirely off
the right edge, so `holding` would delete the sweeps rather than settle them.

AND IT CHANGES NOTHING MEASURABLE. The title is still 1.82% against the oracle:
1.82 at t=261, 1.81 at t=355, 1.79 at t=420. At t=355 my interpolation puts the
leaf's top-left at x ~ -324, off-screen left, where the Decoder's model puts the
quad's CENTRE at 981. Those cannot both be right, and it is not something to tune
away -- it is a disagreement about how the leaf's keyframes become a placed quad,
most likely in the pivot and the rotation about it. Handed back with both
numbers.

So: the exporter no longer drops the data, the composition rule is implemented as
decoded, and the port's largest oracle gap is exactly where it was. Fixing the
export was necessary and not sufficient.

TWO FLAGGED ELEMENTS DELIBERATELY NOT DRAWN, in authored/rendering.json with
reasons. title_jp/ptlogo_eff2 (parent 125%, leaf 100%) is the same shape and is
the element DECISIONS has recorded since P1 as the largest render disagreement --
but the Decoder said plainly "I have not tested it", and drawing it would extend
a decode past the case it was fitted on. pgloading_loop5's leaf is scale (0,0),
and scale-0 is one of the three historical failures this corpus names.

Neither can be adjudicated here: title_jp has no oracle capture, and
verify-screen compares against a renderer that draws no leaves at all, so ANY
leaf drawing increases that divergence whether right or wrong. Its max went
155 -> 232 when they were drawn, and that number is not evidence in either
direction.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01N7FiFFFwbvG2uxdcEh8HyF
This commit is contained in:
Sylpheed port agent
2026-08-29 18:09:43 +00:00
parent 9ad8f63234
commit cb616ab9af
6 changed files with 215 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

58
docs/port/DECISIONS.md
View File

@@ -3996,3 +3996,61 @@ cancelling, the same shape as mine. It is a **shared decode gap, not a defect in
my compositor**, and MISSION's *"Needs a human decision — rotation"* now has a
number attached: **1.82 % of the title's pixels, in a signature that can be
recognised.**
## The leaf composition is decoded and implemented — and it does **not** close the 1.82 %
The Decoder decoded the rule I refused to guess: **draw the leaf on its own
timeline; do not multiply the parent's alpha in.** Multiplying is *refuted*, not
merely unsupported — at the fitted time the parent has expired (its group returns
to 0 at t=250 and holds), so `leaf × parent / 255` predicts zero for both quads
and the sweeps would be invisible. They are drawn.
The fit is worth repeating because of its shape: the game's own composed alpha is
observable in the per-draw vertex colours (`C3FFFFFF`/`B6FFFFFF` = **195** and
**182**), fitting *only those two numbers* against the two leaf ramps gives one
consistent time **t = 355**, and the same t then **predicts** quad centres at 981
and 478 against **992.0** and **467.2** measured. No x entered the fit.
Implemented: `_draw_leaf` runs the leaf unclamped — like the spinning ring, and
for the same reason. Held at its own `rest.t` the leaf sits at **x = 1521**,
entirely off the right edge, so `holding` would delete the sweeps rather than
settle them.
### 🔴 And it changes nothing measurable. The title is still 1.82 %
| t | units | differing |
|---|---|---|
| 4.35 s | 261 | 1.82 % |
| **5.917 s** | **355** | **1.81 %** |
| 7.00 s | 420 | 1.79 % |
**At t=355 my interpolation puts the leaf's top-left at x ≈ −324 — off-screen
left — where the Decoder's model puts the quad's centre at 981.** Those cannot
both be right, and the gap is not something to tune away: it is a disagreement
about how the leaf's keyframes become a placed quad, most likely in the pivot and
the rotation about it. **Handed back with both numbers.**
So the honest state: the exporter no longer drops the data, the composition rule
is implemented as decoded, and **the port's largest oracle gap is exactly where
it was.** Fixing the export was necessary and was not sufficient.
### Two flagged elements deliberately not drawn
`authored/rendering.json` narrows drawing to `ptloop01`/`ptloop02` — what the
decode covers — while the exporter keeps flagging all 15.
* **`title_jp/ptlogo_eff2`** — parent 125 % at (412,96), leaf 100 % at (402,66).
The same shape, and the element `DECISIONS` has recorded since P1 as the
largest render disagreement in the export. The Decoder said plainly *"I have
not tested it."* Drawing it would extend a decode past the case it was fitted
on — the failure this port has made four times this session.
* **`pgloading_loop5`** — leaf scale **(0, 0)**. A zero scale is one of the three
historical failures this corpus names, so it is exactly where a guess costs
most.
⚠️ **And neither can be adjudicated here.** `title_jp` has no oracle capture, and
`verify-screen` compares against `sylpheed-cli`, **which draws no leaves at all**
— so *any* leaf drawing increases that divergence whether it is right or wrong.
Its `max` went 155 → 232 when they were drawn, and **that number is not evidence
in either direction.** Recognising it as uninformative is the reason it did not
become a justification.