Sylpheed/docs/agents/PLAYTEST-2026-09-02.md

# Play-test, 2026-09-02 — **the splash does not animate at all**

**This is the only thing either agent works on until it is fixed.**

The human, watching the port on real hardware, on a GPU, at ~140 fps:

> *"The port does no blur animation at all! I cannot discern if there is any
> animation at all. The logos just switch without the animation."*

## Measured, not paraphrased

Filmed from a **real boot** at 0.05 s (`--film`), then per-frame change measured
with [`tools/motion-census`](../../tools/motion-census):

| | |
|---|---|
| splash moves | **1.30 s of 7.95 s — 16.4 %** |
| publisher splash | 0.30 s of motion, then **3.20 s frozen** |
| developer splash | 0.35 s + 0.25 s, then **2.40 s frozen** |
| distinct luma states in 7.95 s | **26** |

A 45-unit build-in cannot be drawn in 26 states, and a fade does not hold one
picture for 3.20 s. **This is a switch with a flicker on either side.**

The frame counter says 24.8 fps achieved. Both are true: the port is *drawing*
25 times a second and *changing* almost never.

## 🔴 Why three instruments all said it was correct

This is the part that matters more than the bug, because it is the fourth time
this shape has cost a milestone.

| instrument | what it proved | what it could not see |
|---|---|---|
| **frozen sweep** (`--time=`, 3 units a step) | the renderer CAN draw pose *N* | whether the poses are ever drawn **in sequence, while running** |
| **settled comparison** (0.01 % against the capture) | the resting pose is right | a screen frozen 84 % of the time matches a settled reference **perfectly — that is what frozen means** |
| **achieved-fps counter** | frames are being drawn | drawing the **same pixels** 25×/s scores identically to animating |

> **Every one measured throughput or a pose. Not one measured CHANGE.**

That is why the port could write *"the companion quads are drawn, verified by a
frozen sweep"* and be simultaneously right and useless: the sweep drives the
clock by hand. It is the same defect as `InputEventAction` bypassing the input
map — **the instrument sat below the thing that was broken**, so the thing that
was broken could not appear in it.

`tools/motion-census` exists to close this class. It measures change and nothing
else, and its `--selftest` proves it separates a fade (97.4 % moving) from a
switch (2.6 %) from a frozen film (0.0 %) — because a detector that cannot tell
those apart would report the same green line on all three.

## What both agents do now

**Nothing else.** Not the clock rate, not the plate, not blend, not audio. This
first.

### Port

1. **Reproduce it** with `--film` + `motion-census` before changing anything, and
   quote the numbers. If your run does not reproduce 16.4 %, say so — the
   disagreement is then the finding.
2. **Find why the clock does not advance the poses.** Candidates, unranked and
   none established: the keyframe interpolation returns the same pose for a
   range of *t*; `rest()`/plateau logic snapping to an endpoint; the group clock
   not integrating; interpolation between keyframes not happening at all
   (nearest-keyframe rather than lerp); the screen advancing by *keyframe index*
   instead of by time.
3. **Every fix is gated by a film**, never by a still. A change that improves a
   settled frame and leaves the film at 16 % has not fixed this.
4. `motion-census` goes into `check-all`, so a future regression fails a check
   instead of waiting for a human.

### Decoder — **map the whole graphics pipeline, end to end**

The human's instruction, in their words: *"get the whole graphics pipeline, from
the xex/pe + the disc files to the final screen displayed, and take Xenia Canary
processing into account too."*

So: one continuous account, each stage with evidence and each labelled by the
instrument that produced it —

```
disc bytes  →  RATC/T8aD decode  →  what the GAME CODE does per frame
            →  the draw calls it submits  →  Canary's own processing
            →  the presented frame
```

Specifically, and none of it inferable from a file alone:

* **The game's per-frame update.** Which code advances a UI group's clock, in
  what units, and what it does *between* keyframes — does it interpolate, or
  hold to the next key? That single question decides whether the port should
  lerp at all. It is in the image; find the function.
* **What the game submits per frame during the splash** — the draw list frame by
  frame, not one settled frame. If the alpha changes, it changes *somewhere*
  observable: a vertex colour, a PS constant, a blend factor, a texture swap.
  **Name which, with the per-frame series.**
* **What Canary does to it.** Present cadence, any resolve/scaling/gamma between
  the guest's draw and the pixels a capture records. A capture is evidence about
  *Canary's output*, and the difference between that and the guest's intent has
  bitten this corpus before (the `kernel_display_gamma_type` entry).

⚠️ **Deliver a per-frame SERIES, not a settled value.** Follow
[`TEMPORAL-VERIFICATION.md`](TEMPORAL-VERIFICATION.md): film it, align by
content, report ordering/counts/durations. The port needs to know what the
alpha *trajectory* is, and a single frame cannot carry one.

## And this is a refutation the port should record against itself

`BLOCKED.md` H2 currently reads ✅ **ANSWERED**, on the strength of the frozen
sweep. The mechanism half stands — the blur is a baked companion texture, that
is decoded and correct. **The behaviour half does not**: the port draws those
quads and does not animate them, so *"the companions are drawn"* was true and
did not mean what the row used it to mean.