fabi/Syplheed-Reborn
Archived
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

re(ui): quantify what changing the rest rule would do disc-wide

Browse Source 
The open question was whether "last keyframe" holds beyond the two
elements I could score against a capture. It cannot be scored disc-wide --
only two ambiguous elements sit on a screen with a live capture -- but the
blast radius can be measured, and it argues the same way.

  genuinely ambiguous elements                       2 305
    the two rules AGREE on                             409  (17.7 %)
    they DIFFER on                                   1 896  (82.3 %)

  dwell (current): invisible pose 1 711 (74.2 %), zero-scale 195 (8.5 %)
  last           : invisible pose 1 618 (70.2 %), zero-scale  43 (1.9 %)

Two things follow. It is not a marginal choice: the rules disagree on 82%
of the affected elements, so "either is fine" is not available. And the
current rule produces 4.5x more degenerate poses -- a zero-scale pose is
collapsed to nothing, i.e. an element's PRE-ROLL before it has grown in,
which is definitionally not a rest. 195 elements currently rest at a frame
they are only passing through, against 43 under last.

That is an argument from the data's own structure rather than from the two
captures, and it points the same direction.

Kept honest: it is indirect. Fewer degenerate results is not the same as
more correct results, and last still returns an invisible pose 70% of the
time -- right for a transient element, wrong for a persistent one. The
default stays put; the numbers are in HANDOFF for whoever decides.
This commit is contained in:
Sylpheed RE agent
2026-08-29 04:24:40 +00:00
parent 93e9b185ea
commit 515456c59a
4 changed files with 112 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -491,3 +491,33 @@ provably identical on the other three, but it would alter the rest pose of
✅ Unaffected by the earlier correction: all **195** zero-scale rest poses are
inside the genuinely-ambiguous 2 305 — none is a single-keyframe element.
### The disc-wide blast radius — measurable even though the rule is not scorable there
Only two ambiguous elements sit on a screen with a live capture, so the rule
cannot be *scored* disc-wide. What can be quantified is what changing it would
do ([`tools/re-capture/rest_rule_blast_radius.py`](../../../tools/re-capture/rest_rule_blast_radius.py),
[data](../data/rest-rule-blast-radius.txt)):
| | dwell (current) | `last` |
|---|---|---|
| the two rules **differ** | **1 896 of 2 305 (82.3 %)** | |
| returns an **invisible** pose | 1 711 (74.2 %) | 1 618 (70.2 %) |
| returns a **zero-scale** pose | **195 (8.5 %)** | **43 (1.9 %)** |
Two things worth reading off this.
**It is not a marginal choice.** The rules disagree on 82 % of the affected
elements, so "either is fine" is not available.
**The current rule produces 4.5× more degenerate poses.** A zero-scale pose is
*collapsed to nothing* ([rat layout](ui-rat-layout.md)) — an element's **pre-roll**,
before it has grown in. A pre-roll is definitionally not a rest, so 195 elements
currently rest at a frame the element is only passing through, against 43 under
`last`. That is an argument from the data's own structure rather than from the
two captures, and it points the same way they do.
🟡 It remains **indirect**: fewer degenerate results is not the same as more
correct results, and `last` still returns an invisible pose 70 % of the time —
which for a transient element may well be right, and for a persistent one would
be wrong. The default stays put.