From be1485f7b4785905c5cc1d1b1cc2ecfd17234314 Mon Sep 17 00:00:00 2001 From: sylph-decoder Date: Sun, 30 Aug 2026 12:59:29 +0000 Subject: [PATCH] re: RETRACT the splash settle windows -- --build takes an ORDINAL, not an entry 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) Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v --- .../examples/settle_window_check.rs | 27 ++++++++++ .../data/splash-settle-window-retraction.txt | 54 +++++++++++++++++++ docs/re/structures/ui-resting-pose.md | 31 ++++++----- 3 files changed, 100 insertions(+), 12 deletions(-) create mode 100644 crates/sylpheed-formats/examples/settle_window_check.rs create mode 100644 docs/re/data/splash-settle-window-retraction.txt diff --git a/crates/sylpheed-formats/examples/settle_window_check.rs b/crates/sylpheed-formats/examples/settle_window_check.rs new file mode 100644 index 00000000..f7d4a2bc --- /dev/null +++ b/crates/sylpheed-formats/examples/settle_window_check.rs @@ -0,0 +1,27 @@ +//! Where does `settle_window()`'s answer come from? The port agent recomputes the +//! publisher splash's widest keyframe-free gap as 190 units; `--settle` reports 8. +//! One of the two readings is wrong and the file settles it. +//! cargo run -p sylpheed-formats --example settle_window_check -- +use sylpheed_formats::{pak::PakArchive, ui_layout}; +use std::path::PathBuf; +fn main() { + let b: usize = std::env::args().nth(1).unwrap_or("10".into()).parse().unwrap(); + let root = PathBuf::from(std::env::var("SYLPHEED_DISC").expect("SYLPHEED_DISC")); + let ar = PakArchive::open(root.join("dat/GP_TITLE.pak")).expect("GP_TITLE"); + let by = ar.read(&ar.entries()[b]).expect("entry"); + let build = ui_layout::parse_build(&by).expect("parse"); + println!("entry {b}: {} elements", build.elements.len()); + for el in &build.elements { + let ts: Vec = el.keyframes.iter() + .map(|k| k.time.map(|v| v.to_string()).unwrap_or("-".into())).collect(); + println!(" {:26} [{}]", el.name, ts.join(" ")); + } + let mut ts: Vec = build.elements.iter() + .flat_map(|e| e.keyframes.iter().filter_map(|k| k.time)).collect(); + ts.sort_unstable(); ts.dedup(); + println!("\nunion of all element keyframe times: {ts:?}"); + let gaps: Vec<(u32,u32,u32)> = ts.windows(2).map(|w| (w[1]-w[0], w[0], w[1])).collect(); + let mut g = gaps.clone(); g.sort_by(|a,b| b.0.cmp(&a.0)); + println!("widest gaps: {:?}", &g[..g.len().min(4)]); + println!("settle_window() reports {:?}", build.settle_window()); +} diff --git a/docs/re/data/splash-settle-window-retraction.txt b/docs/re/data/splash-settle-window-retraction.txt new file mode 100644 index 00000000..2e4a65c5 --- /dev/null +++ b/docs/re/data/splash-settle-window-retraction.txt @@ -0,0 +1,54 @@ +# RETRACTION: the splash settle windows are 190 and 145, not 8 -- and the +# width hypothesis is NOT refuted. 2026-08-30. +# +# The port agent recomputed the publisher splash's widest keyframe-free gap +# as 190 units against my reported 8, and said one reading must be wrong. +# It was mine, and the library was never wrong -- only my invocation. +# +# examples/settle_window_check.rs, straight from the file: +# +# entry 10 palogo_sqex.t32 [0 15 30 235 239 251 255] +# palogo_sqex_eff.t32 [0 15 30 45] +# union [0,15,30,45,235,239,251,255] widest gap 45->235 = 190 +# settle_window() -> Some((45, 235)) <- 190, matches the port +# +# entry 11 union [0,15,30,45,190,194,206,210] widest gap 45->190 = 145 +# settle_window() -> Some((45, 190)) <- 145, matches the port +# +# 🔴 THE CAUSE: 'screen render --build N' takes a BUILD ORDINAL, not a pak +# entry. screen list says so directly: +# [10] entry 12 [11] entry 15 +# The splashes (entries 10 and 11) are not screen builds at all. My +# '--build 10' and '--build 11' rendered the LOADING screens. +# +# This is the foot-gun HANDOFF already documents -- the port caught it months +# ago, writing that an ordinal-keyed '10'/'11' names the publisher wordmark +# and developer logos as loading screens 'and everything still validates'. +# I walked into the mirror image of it. +# +# WHAT THIS RETRACTS: +# +# 1. 'Width does not predict quality' -- WITHDRAWN. It rested entirely on the +# splashes being width 8 while winning 75x. They are width 190 and 145, +# the WIDEST of the five screens. Width and mid-ramp are now perfectly +# confounded across every screen either of us has measured, exactly as the +# port said. The port's predictor may still be the mechanism; this evidence +# does not establish it over width. +# +# 2. 'My rest_vs_settle filter excluded the splashes' -- WITHDRAWN. At 190 and +# 145 they were never near the 10-unit cutoff. The filter's other fault +# stands: it admitted the 10-19 bucket, the worst at 45.1 % mid-ramp. +# +# 3. The splash rows of settle-vs-rest-against-captures.txt -- 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 showing up in the only place +# my instrument could report it. +# +# ✅ WHAT SURVIVES: the title row (build ordinal 4 = entry 4, correct), where +# settle beats rest 4.6x on differing area at an interior gamma. And the +# disc-wide censuses, which iterate pak entries directly and never touch +# the ordinal path. +# +# ⚠️ To render a splash: entries 10/11 need 'screen render --all', which +# renumbers --build over every composable bundle. diff --git a/docs/re/structures/ui-resting-pose.md b/docs/re/structures/ui-resting-pose.md index 6ed3a0fc..72f69999 100644 --- a/docs/re/structures/ui-resting-pose.md +++ b/docs/re/structures/ui-resting-pose.md @@ -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