From a46a922bc8be5a8f17b9d94c50dd587eab0e4dcc Mon Sep 17 00:00:00 2001 From: Sylpheed RE agent Date: Sat, 29 Aug 2026 04:37:59 +0000 Subject: [PATCH] re(ui): a static composite is only meaningful for a screen that settles The model's sharpest prediction, tested with its control. The draw log says that on the developer splash the _eff glows are drawn on frames 94-115 and the logos on 116-211, so at the moment the reference capture was taken EVERY glow is already finished -- including the two that have plateaus and which rest_plateau therefore renders visible. Suppressing them should help on the splashes and hurt where a screen genuinely settles. publisher splash +0.9604 -> +0.9982 +0.0377 developer splash +0.9659 -> +0.9980 +0.0321 title (control) +0.9500 -> +0.9480 -0.0020 main menu(control) +0.9460 -> +0.8544 -0.0916 EXTRAS (control) +0.9440 -> +0.8370 -0.1070 Both splashes jump to about 0.998; all three persistent screens get worse. The control is what makes this a finding rather than a coincidence: the same edit helps exactly where the model says it should and hurts exactly where it says it should not. So rest_plateau is not over-drawing in general -- it over-draws on TRANSIENT screens. A plateau mid-animation means the element is held at that point in the timeline, not that it is on screen once the screen has settled. Where a screen settles, the held pose IS the settled pose and the rule is measurably right. And that answers the question left open several iterations ago -- what "rest" means for a transient element. It does not mean anything: the splashes never rest. A static composite of them can match a chosen frame, and about 0.998 is what these captures' frame is worth, but the format does not answer a question the screen never poses. For the port: play the timeline for the two splashes, which the settled keyframe timing now supports, and composite statically for title, main menu and EXTRAS. METHOD: an edit that improves one set of cases is only interesting once you have shown it damages the cases where it should. --- .../examples/plateauless_suppression.rs | 8 ++++ docs/port/HANDOFF.md | 15 ++++++ docs/re/METHOD.md | 8 ++++ docs/re/REFUTED.md | 8 ++++ docs/re/structures/ui-resting-pose.md | 47 +++++++++++++++++++ 5 files changed, 86 insertions(+) diff --git a/crates/sylpheed-formats/examples/plateauless_suppression.rs b/crates/sylpheed-formats/examples/plateauless_suppression.rs index 0a004368..e8ef1890 100644 --- a/crates/sylpheed-formats/examples/plateauless_suppression.rs +++ b/crates/sylpheed-formats/examples/plateauless_suppression.rs @@ -25,7 +25,15 @@ fn main() { let bytes = ar.read(&entries[idx]).expect("read"); let Some(build) = ui_layout::parse_build(&bytes) else { continue }; // plateau-less = rest() had to guess: no two adjacent keyframes share a pose + // Default: suppress plateau-less elements. With SUPPRESS_SUBSTR set, + // suppress every element whose NAME contains it instead — used to test + // the entry→hold→exit model's prediction that the splash glows are all + // finished by the moment the logos are up. + let by_name = std::env::var("SUPPRESS_SUBSTR").ok(); let mask: Vec = build.elements.iter().map(|e| { + if let Some(sub) = &by_name { + return !e.name.to_lowercase().contains(sub.as_str()); + } let k = &e.keyframes; (0..k.len().saturating_sub(1)).any(|i| { k[i].fade == k[i+1].fade && k[i].scale_x == k[i+1].scale_x diff --git a/docs/port/HANDOFF.md b/docs/port/HANDOFF.md index 832d75d0..b5ab0400 100644 --- a/docs/port/HANDOFF.md +++ b/docs/port/HANDOFF.md @@ -328,6 +328,21 @@ authored version can be deleted. ⚠️ Reach: static composites at rest against single frames — this says nothing about animation. +* ✅ **A static composite is only meaningful for a screen that SETTLES — the two + splashes are animations.** Measured with its control: suppressing the `_eff` + glows takes the **publisher splash 0.9604 → 0.9982** and the **developer splash + 0.9659 → 0.9980**, while the same edit makes the title −0.002, the main menu + **−0.092** and `EXTRAS` **−0.107** worse. The draw log says why — on the + developer splash the glows draw on frames 94–115 and the logos on 116–211, so + at the captured moment every glow is already finished, including the two with + plateaus that `rest_plateau` renders visible. + So `rest_plateau` is right where a screen settles and over-draws where it does + not. **There is no "resting pose" for the splashes** — they play through and + leave, and a static composite of them is a picture of one arbitrary frame + (≈0.998 for the frame these captures hold). **Play the timeline for the two + splashes; composite statically for title / main menu / `EXTRAS`.** + [`structures/ui-resting-pose.md`](../re/structures/ui-resting-pose.md) + * **Menu order is geometric.** Buttons sorted top-to-bottom by resting Y. This is ✅ correct for a vertical menu and is **not** a decoded neighbour graph — the disc's real navigation structure is unknown, and `opt ` is *not* a focus link diff --git a/docs/re/METHOD.md b/docs/re/METHOD.md index 4b233d56..10be9a71 100644 --- a/docs/re/METHOD.md +++ b/docs/re/METHOD.md @@ -787,3 +787,11 @@ agent's loop prompt, i.e. nowhere durable. See [`README.md`](README.md) for the completion* while the screen is still up. The exit is the dismissal, so a displayed screen never reaches its last keyframe. Both claims survive; what was wrong was the step between them that I supplied. +* **The control is what turns a helpful edit into a finding.** Suppressing the + `_eff` glows raised both splashes from ≈0.96 to ≈0.998 — on its own that reads + as "we over-draw glows". Running the same edit on the three screens that settle + made them **worse** (−0.002, −0.092, −0.107), which is what makes the result + mean something specific: the over-draw is confined to transient screens, where + a plateau mid-animation is not evidence the element is on screen at rest. An + edit that improves one set of cases is only interesting once you have shown it + damages the cases where it should. diff --git a/docs/re/REFUTED.md b/docs/re/REFUTED.md index ca115ab9..761ef09c 100644 --- a/docs/re/REFUTED.md +++ b/docs/re/REFUTED.md @@ -555,3 +555,11 @@ neighbourhood, not just the line. group is entry → hold → exit and the exit is the screen's *dismissal*: a displayed screen sits at the hold, not at its final pose. [`ui-resting-pose.md`](structures/ui-resting-pose.md) +* "`rest_plateau` renders elements the game has already finished with" (as a + general claim) → **narrowed by its control.** It holds on **transient** screens + only: suppressing the finished glows takes the two splashes from 0.9604/0.9659 + to **0.9982/0.9980**, while the same edit costs the title 0.002, the main menu + **0.092** and `EXTRAS` **0.107**. A plateau mid-animation is evidence the + element is held at that point in the timeline, not that it is on screen once the + screen has settled — and where a screen does settle, the rule is right. + [`ui-resting-pose.md`](structures/ui-resting-pose.md) diff --git a/docs/re/structures/ui-resting-pose.md b/docs/re/structures/ui-resting-pose.md index eecfaa31..87eeca9b 100644 --- a/docs/re/structures/ui-resting-pose.md +++ b/docs/re/structures/ui-resting-pose.md @@ -603,3 +603,50 @@ for 12. plateau-less element's animation has finished by the time the screen is settled. The draw log establishes this for the two splash glows (drawn on frames 94–115, with the logos on 116–211) and nothing establishes it for the rest. + +--- + +## ✅ A static "rest" composite is only meaningful for a screen that SETTLES + +**2026-08-29.** The model's sharpest prediction, tested with its control. + +The draw log says that on the developer splash the `_eff` glows are drawn on +frames **94–115** and the logos on **116–211** — so at the moment the reference +capture was taken, *every* glow is already finished, including the two that have +plateaus and which `rest_plateau` therefore renders visible. Suppressing them +should improve the match. Suppressing them on a screen that genuinely settles +should make it worse. + +| screen | as-is | `eff` elements suppressed | Δ | +|---|---|---|---| +| **publisher splash** | +0.9604 | **+0.9982** | **+0.0377** | +| **developer splash** | +0.9659 | **+0.9980** | **+0.0321** | +| title *(control)* | +0.9500 | +0.9480 | −0.0020 | +| main menu *(control)* | +0.9460 | +0.8544 | **−0.0916** | +| `EXTRAS` *(control)* | +0.9440 | +0.8370 | **−0.1070** | + +Both splashes jump to **≈0.998**; all three persistent screens get worse. The +control is what makes this a finding rather than a coincidence — the same edit +helps on exactly the screens the model says it should and hurts on exactly the +ones it says it should not. + +### What this settles + +**`rest_plateau` is not over-drawing in general — it over-draws on transient +screens.** A plateau in the middle of an animation is evidence the element is +held *at that point in the timeline*, not that it is on screen when the screen +has settled. On a screen that settles, the held pose is the settled pose and the +rule is right (the controls). On a screen that plays through and leaves, there is +no settled moment at all, and the reference capture is a picture of one arbitrary +frame. + +⚠️ **So the honest answer to "what is the rest pose of a transient screen" is: +there isn't one.** The splashes are animations. A static composite of them can +match a chosen frame — ≈0.998 for the frame these captures hold — but "the +resting pose" is a question the format does not answer because the screen never +rests. + +✅ For the port: **play the timeline for the splashes**, which the settled +keyframe timing now supports ([time unit](../ui-keyframe-time-unit.md)). Use a +static composite for the title, main menu and `EXTRAS`, where the screen does +settle and `rest_plateau` is measurably right.