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

docs: record the paint-order key as landed, with what it left unsettled

Browse Source
This commit is contained in:
Sylpheed RE agent
2026-08-19 05:43:29 +00:00
parent deff5a4d6d
commit fb4f035f08
1 changed files with 23 additions and 9 deletions
Download Patch File Download Diff File Expand all files Collapse all files

32
docs/re/BACKLOG.md
View File

@@ -31,16 +31,30 @@ the per-element visibility toggles still line up.
**Derivation found (2026-08-19)**: the order sorts by the word at **`+0x08` of
the T8aD sprite header** — non-decreasing in paint order on both measured
screens, with no inversion, and on the splash it explains the whole permutation.
See [`structures/ui-paint-order-key.md`](structures/ui-paint-order-key.md). Not
yet wired into the compositor, and its ties are unexplained.
See [`structures/ui-paint-order-key.md`](structures/ui-paint-order-key.md).
**Still open:** the tie-break, what the field's bits mean, and a third measured
screen to promote this from "holds on two" to a rule. Also still open, and
unaffected by the key: deriving the order for screens nobody has captured. It is not in the declaration entry, the placement region or the runtime
element record (all measured); what remains is the loader that builds the child
list. The order is deterministic across boots, so a rule exists — it just has not
been found, and every screen without a measured order still paints in declaration
order.
**Wired into the compositor (2026-08-19)** and regression-checked. `compose`
sorts by the key for every build except the two whose measured order is hard
coded. It reorders **341 of 965 builds**, and a disc-gated test asserts every
composite's draw list is strictly increasing in `(key, declaration index)`.
Against the two screens the corpus had already verified against the running game
— the tutorial PAUSE menu and the title main menu — the new order changes 3.8 %
and 1.1 % of pixels, max delta 45/255, **with no layout change**: only blends
where translucent sprites overlap.
**Still open:**
* 🟡 Which order is more faithful on those two verified screens. The difference
is too small to decide against the committed side-by-side oracle and no fresh
framebuffer capture of either exists. First thing to check if one is taken.
* ❔ The tie-break. Two groups share a key and the game paints them in an order
that is not declaration order; the compositor keeps declaration order there.
* ❔ What the field's bits mean — `0x8000`/`0x80a0`/`0xa110` look like flag words
with a layer in some bits, not a plain depth. Sorting the whole word works on
both measured screens; which bits carry the layer is unknown.
* ❔ A third measured permutation, to promote "holds on two" to a rule. The
cheapest is a screen whose object is resident at the same time as the title's.
* ❔ 341 builds now composite in an order no capture has checked.
The investigation that got here follows, kept in full because most of it is
refutations that were worth the cost.