Sylpheed/docs/re/menu-idle-and-b-2026-08-29.md

🔴 The main menu does NOT self-return to the title — and three "latencies" were my own pipeline

Status: one ✅ measured negative, one 🟡 ordering-only result, and one 🔴 instrument defect that voids three numbers I took the same day. Taken 2026-08-29.

✅ Refuted: "an ~8–10 s idle returns to the title" does not apply to the main menu

HANDOFF's residue table downgraded Ⓑ leaves the main menu to authored, on the grounds that "an ~8–10 s idle also returns to the title, and nobody has separated the two". That reason is now gone.

Measured: the main menu was held with no input at all and classified every ~1.2 s by screen_match.py:

phase	duration untouched	screens seen
period capture	24 s	menu only
idle probe	60 s (49 samples)	menu only

Correlation against the committed main-menu capture never moved outside 0.9245 – 0.9249 across the whole idle window — not a drift, not a fade, a screen sitting still. Conservatively that is ≥ 60 s of continuous idle with no self-return, against a claim of 8–10 s.

✅ And the 8–10 s idle is real — it belongs to the TITLE. Immediately after this run, a probe that expected to find the title still on screen found it had left on its own into the attract movie. So the corpus's idle timer is a property of the title screen (title → ADV.wmv → title), and the residue table attached it to the wrong screen.

What this gives the port: the idle alternative that made Ⓑ unprovable is refuted on the screen in question. Ⓑ is no longer competing with a timer there.

🟡 Ⓑ on the main menu: the ordering survives, the timing does not

Ⓑ was delivered — Canary's own log records [file-pad] keystroke vk=5801 down / up and XamInputGetKeystrokeEx -> user=0 vk=5801, so this is not a dropped press. In both runs the menu was followed by the title, and in both runs Ⓑ was the only input in a window of ≥ 100 s either side.

🟡 But it is still two observations with a confound I cannot yet exclude, and the reason is the next section: the "latency" I measured is worthless, so I cannot say the return followed Ⓑ promptly. What stands is ordering plus the absence of any other cause:

• no input for ≥ 100 s before → no transition;
• Ⓑ delivered → transition to the title.

Classification: measured ordering, unmeasured timing. The port should keep Ⓑ→title, and it is now better supported than "authored" — but it is not yet a timed measurement.

🔴 The defect: an oracle that cost 1503 ms per frame produced three fake latencies

screen_match.classify_array does a ±8 px ZNCC search over a 675×1279 surface against two references. Measured: 1503 ms per frame. A probe calling it on every frame of an 8 fps x11grab stream therefore drained the pipe at 0.64 frames/s — verified from the probe's own trace, 107 samples over 166 s.

The pipe backed up at ~7.4 fps, so every frame classified was stale, and increasingly so. That is not a subtle bias; it manufactured three numbers:

reported	actually
plate appears 24.66 s after the title art	unknown
Ⓑ → title in 15.58 s (run 1)	unknown
Ⓑ → title in 25.60 s (run 2)	unknown
Ⓐ → menu in 20.26 s	unknown

🔴 All four are withdrawn. The tell was that they are all ~20–25 s: a screen transition, a button press and a plate fade do not share a duration, but a backlog does. The two Ⓑ figures growing 15.6 → 25.6 s across a longer run is the backlog accumulating, and it is the signature to remember.

⚠️ What a backlog does and does not destroy. It delays every frame by the same growing amount, so it preserves ordering and destroys durations. That is why the ordering results above survive and every duration here does not.

✅ Fixed and re-controlled. screen_match now has a fast=True path (4× decimation, ±2 decimated px) at 38–75 ms, a 20–60× reduction, and the control was re-run on both paths: 8/8 each, with the fast path agreeing with the exact path to ±0.005 on every score.

✅ The ring measurements are NOT affected, and this was checked rather than assumed: ring_period.py does a greyscale conversion and a crop per frame, and achieved 15.03 fps against a requested 15 — it kept up exactly, so its timestamps carry no backlog. Its period also has an internal check a drifting clock cannot pass: eight evenly spaced autocorrelation peaks (focus-ring-spin-measured.md).

🟡 The PRESS Ⓐ plate: sequence answered, duration not

The port asked whether the boot title is build 4 alone, build 4 with the plate composited from the start, or build 4 then the plate after a delay.

✅ It is the third. On the boot title the green-Ⓐ glyph count went 154 → 781 with the title art already matching at 0.946. The 154 is the decisive number: the committed no-plate capture live-title-build4-no-plate.png reads 159 with the same counter, and plate titles read 753 / 977 / 1493. So the title genuinely presents without the plate first, and the plate arrives afterwards.

🔴 How long afterwards is NOT measured — that figure came from the backlogged probe and is withdrawn with the rest. The port needs one more run with the fast path to get it.

Instrument controls, now committed

The negative controls for screen_match are movie frames, because that is the class the oracle exists to reject — a statistics-based oracle (green/white/mean) called a frame of ADV.wmv containing a bright green laser title, and a probe built on it tapped Ⓐ into the movie and then waited 120 s for a menu that was never coming.

An earlier version of the control list pointed at two scratch grabs, and a later run of the same probe overwrote one of them — turning a negative control into a title frame and failing the control for the wrong reason. They are now committed fixtures under captures/instrument-controls/.