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

port: transcribe the sweeps' additive blend, and re-run my own menu-looping evidence with it

Browse Source 
ui-blend-mode-measured.md names both rotated sweep strips additive in the same row
as the frames. Those are ptloop01/ptloop02 here, now in additive_elements for both
measured screens. It changes nothing visible: on the menus the port runs the leaf
group once and parks it off-screen, and suppressing both sprites at leaf-time 100,
200 and 300 changes 0 pixels each time. It is in the file because it is measured.

Refutation attempt on their identification, and it survives with a number of mine.
The automatic matcher reports "no match" for those two draws; they rest on one
control reproducing heights 1134 and 1303. Rendering the menu at a phase where the
sweeps are on screen and suppressing them gives a footprint 884 px wide against
their 889.6 -- 0.6 % apart, derived without using their number. The heights differ
as they should: my bbox is clipped by the screen, theirs is the full quad extent.

The blend was a confound in my own earlier evidence. loop_leaf_why scoped looping
to the title partly on a phase sweep of mine that drew the sweeps ALPHA-OVER, so
an on-screen sweep was composited wrongly and then scored against the capture. Re-
run with additive and looping enabled for the menu, through a scratch export root
so the repo was untouched: parked 0.0208 %, phase 150 on-screen 0.0851 % with the
sweeps painting 58 027 px, other on-screen phases 0.086-0.122 %.

The conclusion held and got stronger -- 3x with the wrong blend, 4-6x with the
right one -- so the scoping stays and the correction is what is recorded. Still one
capture, and best-match is still weak evidence for an absence.

And a reading of the new log that I did not make: it shows both sweeps SUBMITTED
on the main menu in every frame group, which is not evidence they animate there. A
quad parked off-screen at x=1521 is still a draw call. The log settles the blend
and not the visibility, and both questions arrived in the same artefact.
This commit is contained in:
Sylpheed port agent
2026-08-31 06:23:19 +00:00
parent c453d8dade
commit 0ca6d254f8
2 changed files with 121 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files

67
docs/port/DECISIONS.md
View File

@@ -9,7 +9,7 @@ dies, which is what this file is for.
<!-- INDEX: generated by tools/port/index-decisions -- do not hand-edit -->
332 sections. Search this before re-deriving anything.
333 sections. Search this before re-deriving anything.
* [P0 — the exporter, 2026-08-28](#p0--the-exporter-2026-08-28)
* [P1 — Godot draws the screen, 2026-08-28](#p1--godot-draws-the-screen-2026-08-28)
@@ -343,6 +343,7 @@ dies, which is what this file is for.
* [Refutation attempt: the Decoder's kind-0 claim survives, checked from my own data](#refutation-attempt-the-decoders-kind-0-claim-survives-checked-from-my-own-data)
* [The blend is measured, so the port draws it — main_menu 13.21 → 10.67](#the-blend-is-measured-so-the-port-draws-it--main_menu-1321--1067)
* [🔴 Refuted: my "no fully-opaque pixel" sharpener](#refuted-my-no-fully-opaque-pixel-sharpener)
* [The sweeps: a measured blend, a corroborated identification, and a confound in my own evidence](#the-sweeps-a-measured-blend-a-corroborated-identification-and-a-confound-in-my-own-evidence)
<!-- /INDEX -->
## P0 — the exporter, 2026-08-28
@@ -16173,3 +16174,67 @@ survived — the draw path was the right place to look, and it answered — but
reason I gave for looking there was wrong. Recording it because the conclusion
being vindicated is exactly the circumstance in which a bad supporting argument
survives unexamined.
## The sweeps: a measured blend, a corroborated identification, and a confound in my own evidence
### Transcribed: both rotated sweep strips are additive
`ui-blend-mode-measured.md`'s summary table names them additive in the same row as
the frames. They are `ptloop01`/`ptloop02` here, now in `additive_elements` for
both measured screens.
⚠️ **It changes nothing visible today.** On the menus the port runs the leaf group
once and parks it off-screen, so both paint zero pixels at every pose the port can
be put in — checked by suppressing both sprites at leaf-time 100, 200 and 300:
**0 px changed each time**. The entry is there because it is measured, not because
it does anything. What it *does* do is repair the instrument below.
### ✅ Refutation attempt on their identification — survives, with a number of mine
The automatic name matcher reports **"no match"** for those two draws; they are
identified only by the Decoder's control, which reproduces heights **1134** and
**1303** from a different tool in a different session. A claim resting on one
control is worth attacking.
It survives, and my own geometry corroborates it independently: rendering the menu
at a phase where the sweeps are on screen and suppressing them gives a footprint
of **884 × 720**, against the log's **889.6** wide — **0.6 % apart**, and I did not
use their number to produce mine. The heights differ (720 against 1134) exactly as
they should: my bounding box is clipped by the screen, theirs is the untruncated
quad extent.
### 🔴 And the blend was a confound in my *own* prior evidence
`loop_leaf_why` scoped leaf-looping to the title partly on a measurement of mine:
sweeping the phase against `live-main-menu.png`, the port matched best with the
sweeps **off-screen (0.061 %)** and three times worse mid-screen (0.183 %).
**That sweep drew them alpha-over.** They are additive. So an on-screen sweep was
being composited the wrong way and scored against the capture — "mid-screen is
worse" could have been an artefact of my own renderer rather than of the sweeps
being absent. Re-run with the correct blend and looping switched on for the menu,
through a scratch export root so nothing in the repo changed:
| | diff vs capture | sweeps |
|---|---|---|
| phase 0 | **0.0208 %** | 0 px — off screen |
| phase 150 | 0.0851 % | **58 027 px**, bbox 884×720 |
| phase 300 | **0.0205 %** | 0 px — off screen |
| phases 75/225/375/450/525 | 0.086–0.122 % | on screen |
| run-once-and-park (what ships) | **0.0208 %** | parked |
✅ **The conclusion held and strengthened** — the ratio was 3× with the wrong blend
and is **4–6×** with the right one. The capture still matches best with the sweeps
not visible, so the scoping stays and the *correction* is what got recorded.
⚠️ Still one capture, and "best match" is still a weak instrument for an absence.
Fixing the blend cleared one confound; it did not repair that.
### 📌 A draw is not a visible element
The new log shows both sweep strips **submitted on the main menu, in every frame
group**. It would be easy — and wrong — to read that as "the sweeps animate on the
menu", which is exactly the question `loop_leaf_why` left open and would have
contradicted the pixels for no reason. **A quad parked off-screen at x=1521 is
still a draw call.** The log settles the *blend*; it does not settle *visibility*,
and those two came in the same artefact.