From 8fb5ac874384add4d7905cac87b625832ee545a3 Mon Sep 17 00:00:00 2001 From: Sylpheed port agent Date: Sat, 29 Aug 2026 20:30:58 +0000 Subject: [PATCH] port: refute my own "the menu residual is the sweeps", and show the narrow windows are harmless TWO RESULTS, both correcting things I had written. THE NARROW SETTLE WINDOWS ARE NOT A GAP. Adopting the settle instant left main_menu and extras on per-element rest() -- windows of 12 units, below the 30-unit bar -- and I recorded that as something left behind. rest() is malformed only for a TRANSIENT, and the transients are precisely on the screens whose windows are wide: title (76) has ten, publisher_logo (190) and developer_logos (145) have one and three, and main_menu and extras have NONE. The discriminator is returning to dark far before the screen's own end -- ptlogo_back2eff1 is dark again at t=58 while the title runs to t=269 -- as against the ordinary fade-in-hold-fade-out every menu element has, where rest at 255 IS the settled pose. Not claimed as a rule: two screens having narrow windows and no transients could be coincidence, and n=2 is where I have gone wrong before. REFUTED, MINE: "the menu residual is localised on the ptloop sweeps", which I have written twice. It came from reading the BOUNDING BOX, which sat at (441,230) -- the sweep position. Sweeping the leaf's phase against the live-menu capture: 0.063% at t=60, 0.183% mid-screen at t=350, 0.061% parked at t>=600. With them parked the box is 834x358 at (445,167) -- the button column, where the focus signature lives. On extras the same test moves the box (398x295 at the sweep position, then 736x525 spread) while the magnitude barely changes, 0.192% against 0.200%. So the box moves with the sweeps and the residual does not. A bounding box over scattered pixels tells you where the outermost differing pixels are, not where the difference is -- and I had been quoting it as if it localised a cause. verify-capture prints that box, so this is a caution about reading my own tool. And a first piece of evidence on whether the sweeps loop: the disc gives one pass ending parked off-screen, ORACLE-CAPTURES says they "move continuously" which I had read as implying a loop, and the idle menu capture matches best with them OFF-SCREEN. One capture and a weak instrument for an absence, but it is the first evidence either way and it points against looping. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_01N7FiFFFwbvG2uxdcEh8HyF --- docs/port/DECISIONS.md | 63 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 63 insertions(+) diff --git a/docs/port/DECISIONS.md b/docs/port/DECISIONS.md index b86a97b3..984bca1b 100644 --- a/docs/port/DECISIONS.md +++ b/docs/port/DECISIONS.md @@ -4615,3 +4615,66 @@ unexplained exception in `authored/`. **What would change it:** a mechanism in the record, or a gate that measures the build-in against a capture. Until then the port is visibly wrong for two frames during a build-in nobody compares, which is the cheaper of the two wrongs. + +## The narrow settle windows are harmless, and I can now say why + +Adopting the settle instant left `main_menu` and `extras` on per-element `rest()` +— their windows are 12 units, below the 30-unit bar — and I recorded that as a +gap. **It is not one.** `rest()` is malformed only for a **transient**, and the +transients are precisely on the screens whose windows are wide: + +| screen | window | transients | +|---|---|---| +| `title` | 76 | `ptlogo1`/`ptlogo2` ×4, `pteff01`, `ptlogo_back2eff1…5`, `ptlogoall_eff` | +| `publisher_logo` | 190 | `palogo_sqex_eff` | +| `developer_logos` | 145 | `palogo_*_eff` ×3 | +| **`main_menu`** | **12** | **none** | +| **`extras`** | **12** | **none** | + +The discriminator is *returning to dark far before the screen's own end* — +`ptlogo_back2eff1` is dark again at t=58 while the title runs to t=269 — as +opposed to the ordinary fade-in-hold-fade-out that every menu element has, where +`rest` at 255 **is** the settled pose and the final 0 is the exit. + +⚠️ **I am not claiming that as a rule.** Two screens having narrow windows *and* +no transients could be coincidence; it is n = 2, and n = 2 is where I have gone +wrong before. What it does mean is that **nothing measurable is being left on the +table by the 30-unit bar today.** + +## Refuted, mine — "the menu residual is localised on the `ptloop` sweeps" + +I have written that twice. It came from reading the **bounding box** of the +differing pixels, which sat at (441, 230) — the sweep position. Tested by sweeping +the leaf's phase against the live-menu captures: + +| `main_menu`, sweep phase | differing | +|---|---| +| t=60 (barely on screen) | 0.063 % | +| t=350 (mid-screen) | **0.183 %** | +| t≥600 (parked off-screen) | **0.061 %** | + +✅ Two things fall out. **The capture shows no sweeps**: the port matches best +when they are off-screen and three times worse when they cross the middle. And +with them parked the residual's box is **834×358 at (445, 167)** — the *button +column*, which is where the focus signature lives, not the sweep position. + +On `extras` the same test moves the box (398×295 at the sweep position at t=70, +736×525 spread at t=700) while the **magnitude barely changes: 0.192 % against +0.200 %**. + +🔴 **So the box moves with the sweeps and the residual does not.** A bounding box +over scattered pixels tells you where the outermost differing pixels are, **not +where the difference is** — and I had been quoting it as if it localised a cause. +`verify-capture` prints that box, so this is a caution about reading my own tool. + +### And a first piece of evidence on whether the sweeps loop + +The disc gives one pass, t=0…600, ending parked off-screen at x=1521. +`ORACLE-CAPTURES.md` says the title's sweeps *"move continuously"*, which I had +taken as implying a loop. **The idle main-menu capture matches best with them +off-screen**, which is evidence they run once and park. + +⚠️ One capture, one screen, and "best match" is a weak instrument for an absence +— but it is the first evidence either way, and it points against looping. The +loop-length field the Decoder decoded (`+0x08` of a nested record's header) would +settle it outright; it is not in the pinned tag.