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

re: census the settle pose's own failure mode -- and refute the obvious explanation

Browse Source 
The port found ptmsg, the main menu's footer, at alpha 127.5 at that screen's
settle instant. Verified: build 5's window is [44,56] = 12 units and
screen render --settle already prints 'narrow -- this bundle may never settle'.

Disc-wide, elements caught mid-ramp at their screen's settle instant: 25.5 %
overall, 40.9 % on windows under 10 units, 45.1 % on 10-19, falling to 11.7 % and
15.0 % on wide ones.

The obvious reading of that table -- narrow window means the settle pose is bad --
is REFUTED by the screens that motivated the proposal, and I nearly published it.
The two splashes have an 8-unit window, narrower than the main menu's 12, and the
settle pose beats rest() there by 75x and 33x. Width does not predict quality.

The predictor is the port's own statement: the settle pose 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.

And my own rest_vs_settle filter was wrong in both directions: dropping bundles
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.

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:45:33 +00:00
parent 54254a86e1
commit 9d32852724
3 changed files with 164 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -415,6 +415,47 @@ mine**: its publisher splash against a committed capture, **settle-instant pose
differing area, against the game. **That** is the evidence for the proposal; the
numbers above describe its effect and do not establish it.
### 🟡 The candidate's own failure mode — censused, and the obvious explanation is wrong
The port agent found `ptmsg`, the main menu's footer, at **alpha 127.5 of 255** at
that screen's settle instant. Verified: build 5's window is **[44, 56] = 12 units**,
and `screen render --settle` **already prints** *"narrow — this bundle may never
settle"*.
Disc-wide, elements caught **mid-ramp** at their screen's settle instant
([`../data/settle-midramp-census.txt`](../data/settle-midramp-census.txt)):
| settle window | elements | mid-ramp | share |
|---|---|---|---|
| < 10 | 3 571 | 1 460 | 40.9 % |
| **10–19** | 1 755 | 791 | **45.1 %** |
| 20–29 | 935 | 297 | 31.8 % |
| 30–59 | 4 084 | 476 | 11.7 % |
| ≥ 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:
| build | screen | window | port's measurement |
|---|---|---|---|
| 4 | title | 76 | settle wins **9×** |
| 5 | main menu | 12 | settle loses 1.2× |
| **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**.
🔴 **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.
### 🔴 Losing the example did not close the question — it is larger than one element
Disc-wide ([`../data/rest-fallback-census.txt`](../data/rest-fallback-census.txt)):