Sylpheed/docs/re/boot-settle-times-measured.md

✅ settle_time() — when each boot screen actually arrives, measured

Classification: measured. None of this is on the disc as a settle time. The disc declares keyframes; when a screen visibly arrives is a property of the running game, and the port authors these numbers from this page.

Answers the port's standing ask: its boot sequencer paces every screen off rest.t, which is the last hold keyframe and not when a screen arrives — it holds the title for 4.350 s where the build-in is over at about 2 s.

Run: one cold boot, 2026-08-29. Container had no Xenia storage root at all, so this is a fresh profile (--create_profile_if_none) with no shader cache — the slowest case, deliberately. Frame log committed at data/boot-settle-run1.tsv; analysis tools/re-capture/settle_analyse.py.

The instrument was controlled first, and then caught being wrong

title_timing_probe.py --control passed 9/9 on the content classifier — including the movie-frame and difficulty-screen negatives — and 4/4 on the plate detector, before the run. The run itself sampled 2 107 frames in 263.7 s = 7.99 fps against a requested 8, with an independent one-shot grab every 20 s agreeing with the stream to under 1 grey level. So this is not the backlog failure mode that cost this corpus four withdrawn durations.

🔴 And the probe's own title_static mark is still biased early — do not use it for a duration. It fires when the classifier first labels a frame title_* and motion is low, which happens during the crossfade out of the attract movie, before the wordmark has drawn. In this run it fired at t=242.655 while the green-glyph count was still 0; the title art does not reach its steady state until 243.595. Any title_static → plate figure from this probe is therefore inflated by about a second.

The landmarks, taken from content rather than from the probe's marks

The robust landmark is the glyph plateau: the title art alone scores a steady glyph = 154 (the corpus's live-title-build4-no-plate.png scores 159), and the plate takes it past 700.

landmark	t (s)	how
attract movie ends, first title ink	243.362	glyph leaves 0
title art fully drawn	243.595	glyph reaches its steady 154
PRESS Ⓐ plate on	245.842	glyph crosses 400 → 771
Ⓐ pressed	250.983
⚠️ guest load stall	251.601 – 253.135	13 byte-identical frames
main menu arrives	254.707	classifier
main menu settled	255.238	motion below a run-calibrated floor
Ⓑ pressed	262.864
title back	263.346

What the port should author

	measured	⚠️
title build-in (first ink → fully drawn)	0.23 s	from first ink; 1.63 s from the first frame the classifier calls title_*, which is where the crossfade starts
title settled → plate on	2.247 s	matches the disc's declared 120 units
plate pulse period	≈2.37 s	trough-to-trough, 248.098 → 250.467
main menu build-in	0.531 s
Ⓑ → title	0.482 s
Ⓐ → menu	3.763 s	🔴 do not author — contains a 1.53 s emulator load stall, below

🔴 rest.t is confirmed to be the wrong landmark. The title's rest.t is 251 units = 4.183 s; its art is finished at ~2 s and the plate is on at 2.25 s. A sequencer pacing off rest.t holds the title roughly twice as long as the game does.

🟢 A refutation attempt that FAILED — the corpus's 2.13 s plate delay survives

The probe's own marks gave a plate delay of 3.203 s (title_static 242.655 → plate 245.858), against the corpus's two committed runs at 2.138 / 2.132 s and a declared 120 units ≈ 2.0 s. A 50 % disagreement, from a cold-cache boot, is exactly where you would expect the corpus to be wrong.

It is not. The instrument was. Two checks:

• The presentation rate is not depressed in this run. If the boot were running slow, everything timed in game units would stretch together. The plate pulse period is an internal clock for that, and it measures 2.369 s here against the corpus's ≈2.3 s. The run is not slowed.
• Re-measured from content instead of from the probe's mark, steady title art (243.595) → plate on (245.842) is 2.247 s — inside the corpus's range once the ±0.125 s sample interval is allowed for.

✅ So the 2.13 s stands, the 120-unit reading stands, and the 3.203 s is title_static firing during a crossfade. Recorded because a failed refutation is worth as much as a successful one, and because the next person to read the probe's title_static will otherwise repeat it.

🟢 And the load stall reproduces — third independent run, cold cache

title-plate-delay-measured.md records a frozen frame on the Ⓐ path in two runs: 14 frames (1.53 s) and 12 frames (1.39 s), both at surface mean 26.626, and concludes any Ⓐ→menu figure from this harness is an emulator load time rather than a game constant.

This run is a third: 13 frames, 251.601 – 253.135 = 1.53 s, surface mean 26.631, labelled title_plate throughout.

✅ The claim survives, and is now stronger in a way the earlier runs could not show: this boot had no shader cache at all, so the stall is not a warm-cache artefact. ⚠️ One honest qualification — the earlier note says its two runs agreed "to six decimals"; mine agrees only to three (26.631 vs 26.626), so the mean is reproducible but not byte-identical across all three.

Reach

• One run. The durations above are one cold boot. The two that are cross-checked against independent evidence — the plate delay, against the corpus's two runs and the disc's 120 units; the load stall, against two prior runs — are the ones to lean on. The menu build-in (0.531 s) and Ⓑ→title (0.482 s) rest on this run alone. 🟢 The re-take was offered and declined, 2026-08-29: the port authors neither number, is already within ~0.1 s of both from the disc's own keyframes, and asked that no emulator time be spent on its account. Authoring a one-run measurement over a decoded value would gain nothing measurable. Left provisional deliberately rather than for want of a run.
• Sampling is 8 fps, so every landmark carries ±0.125 s, and the guest's own presentation rate cannot be measured from it — 8 fps is far below the ~28 fps the game presents at, so every sample is a distinct guest frame and repeats only appear when the guest itself stalls.
• The splash dwells are not re-measured here; they are already in boot-order-and-splash-dwell.md.

---

🟢 The consumer's own red flag was larger than this measurement supports

Recorded because it is the outcome of the measurement and it went the other way from what the port expected.

The port's standing 🔴 read: "rest.t is the wrong landmark, therefore everything the sequencer paces off it is late." The premise is confirmed here and the consequence is not. Measuring the port the same way this page measures the game — visible span, per-frame greyscale mean — its publisher wordmark runs 4.25 s against three cold boots at 4.297 / 4.604 / 4.370, and its developer logos 3.50 s against 3.508 / 3.503 / 3.366.

⚠️ The discrepancy it was about to chase was the plate-delay trap in a second place. It had been comparing arrival-to-arrival transition timestamps against visible spans; those differ by the exit ramp plus the black hold, about 0.6 s, which was the whole of it — the same shape as timing the title from where it stops animating rather than from where it first appears.

✅ So the generalisation this page supports is narrower than "the sequencer is late": rest.t is the wrong landmark for the title specifically, where it overstates by 4.183 s against ~2 s. Whether any other screen is mis-paced does not follow from it and was not measured here.