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.
This commit is contained in:
Sylpheed RE agent
2026-08-29 04:37:59 +00:00
parent 458585d136
commit 1f2b469f7e
5 changed files with 86 additions and 0 deletions

View File

@@ -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 94115,
with the logos on 116211) 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 **94115** and the logos on **116211** — 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.