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

re: RETRACT the splash settle windows -- --build takes an ORDINAL, not an entry

Browse Source 
The port recomputed the publisher splash's widest keyframe-free gap as 190 units
against my 8 and said one reading must be wrong. Mine was, and the library was
never wrong -- only my invocation.

From the file: entry 10's union of times is [0,15,30,45,235,239,251,255], widest
gap 190, and settle_window() returns Some((45,235)). Entry 11 gives 145. Both
match the port exactly.

The cause is that screen render --build N takes a BUILD ORDINAL. screen list says
[10] entry 12 and [11] entry 15; the splashes are entries 10 and 11 and are not
screen builds at all, so my --build 10/11 rendered the LOADING screens. This is
the foot-gun HANDOFF already documents, which the port caught months ago in the
mirror direction.

Three retractions:

1. 'Width does not predict quality' -- withdrawn. It rested entirely on the
   splashes being width 8 while winning 75x. They are the widest of the five, so
   width and mid-ramp are perfectly confounded across every screen either of us
   has measured and the width hypothesis is NOT refuted.

2. 'My filter excluded the splashes' -- withdrawn; at 190 and 145 they were never
   near the 10-unit cutoff. The other half stands: it admitted the 10-19 bucket,
   the worst at 45.1 %.

3. The splash rows of settle-vs-rest-against-captures -- void. They scored
   loading-screen renders against splash captures. I discarded them for a railed
   gamma fit; the real reason is that they were the wrong screens, and the railing
   was that mismatch surfacing where my instrument could report it.

Surviving: the title row (ordinal 4 = entry 4) and the disc-wide censuses, which
iterate pak entries directly and never touch the ordinal path.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
This commit is contained in:
sylph-decoder
2026-08-30 12:59:29 +00:00
parent ca41b81377
commit 3356343cad
3 changed files with 100 additions and 12 deletions
Download Patch File Download Diff File Expand all files Collapse all files

31
docs/re/structures/ui-resting-pose.md
View File

@@ -434,9 +434,19 @@ Disc-wide, elements caught **mid-ramp** at their screen's settle instant
| ≥ 60 | 3 646 | 548 | 15.0 % |
| **all** | **13 991** | **3 572** | **25.5 %** |
🔴 **The obvious reading — "a narrow window means the settle pose is bad" — is
refuted by the very screens that motivated the proposal**, and I nearly published
it:
🔴 **WITHDRAWN 2026-08-30 — the table below is wrong and so is the conclusion I
drew from it.** `screen render --build N` takes a **build ordinal**, not a pak
entry: `screen list` says `[10] entry 12`, `[11] entry 15`. The splashes are
entries 10 and 11 and are **not screen builds at all**, so my "`--build 10/11`"
windows of 8 are the **loading screens**. From the file the splashes are **190** and
**145** — the *widest* of the five, not the narrowest
([`../data/splash-settle-window-retraction.txt`](../data/splash-settle-window-retraction.txt)).
**So width and mid-ramp are perfectly confounded across every screen either agent
has measured, and the width hypothesis is NOT refuted.** The port's predictor may
still be the mechanism; this evidence does not establish it over width.
The withdrawn reading, kept because the mistake is instructive:
| build | screen | window | port's measurement |
|---|---|---|---|
@@ -445,16 +455,13 @@ it:
| **10** | **publisher** | **8** | settle wins **75×** |
| **11** | **developer** | **8** | settle wins **33×** |
The splashes are **narrower than the menu** and the settle pose wins by 75×. Width
does not predict quality. The predictor is the port's own: it wins decisively where
`rest()` lands on a **transient's peak**, and loses slightly where `rest()` is
already sound and an element **arrives after the window closes**.
~~The splashes are narrower than the menu and the settle pose wins by 75×.~~ **They
are wider. The rows read 8 because they are the loading screens.**
🔴 **And my `rest_vs_settle` filter was wrong in both directions.** Dropping bundles
with a window under 10 units admitted the **10–19** bucket — the *worst*, at 45.1 % —
and **excluded both splashes at width 8**, the strongest evidence *for* the proposal.
A threshold taken from a documented rule of thumb and applied without checking which
screens it admitted and which it threw away.
⚠️ **One half of the filter criticism survives**: dropping bundles with a window
under 10 units admitted the **10–19** bucket, the *worst* at 45.1 % mid-ramp. The
other half — that it excluded the splashes — is withdrawn; at 190 and 145 they were
never near the cutoff.
### 🔴 Losing the example did not close the question — it is larger than one element