Sylpheed/docs/re/structures/boot-splash-gap-measured.md

The black gap between the boot splashes — measured in draws, not luminance

Classification: measured. Xenia Canary, ui_draw_capture.sh GRACE=1 NOTAP=1 ARM=early, 2026-08-29. Evidence: boot-splash-gap-draws.csv.

Why this was open

The port found that its boot had no black frame at all between the publisher and developer splashes, and authored 12 units (0.200 s) by analogy with the menus' transition quad. On the boot path that analogy has nothing behind it: palogo_eff0.prm is a single static keyframe, so the splash bundles declare no fade quad at all.

🔴 And I had agreed with the dismissal that hid it. Told that the residual was 0.03 s against a bound built from two measured ranges plus jitter slack, I said it said more about the bound than the game. It did not — the underlying gap was 0.2 s and the port had been missing it since P3. A plausible explanation for a small number is exactly how a real defect stays hidden.

The measurement

Luminance cannot separate the outgoing screen's fade tail from true black. The draw stream can: it says exactly which frames submit a sprite quad at all.

frames	what is submitted
2 – 20	palogo_sqex_eff (685×90) — the publisher's glow
21 – 125	palogo_sqex (666×65) — the publisher wordmark, fading to alpha 7
126 – 129	🔴 nothing — 4 frames with no sprite quad at all
130 – 153	the developer splash, fading in from alpha 34

The gap is 4 presented frames, and it is the only such run anywhere between the first and last sprite of the sequence.

Converting it without a frame rate

The run's presented rate is not usable — measured at 13.1 fps while the title was up, against the corpus's 28 fps for other runs, and it is not stable enough to convert a 4-frame interval.

So the disc's own timeline is the clock. palogo_sqex declares alpha ≥ 1 from t ≈ 15.06 to t ≈ 254.9 — 239.8 units — and is drawn in 105 frames:

2.284 units per presented frame, from the same screen in the same capture. (The title capture, independently, gave 2.231.)

	units	seconds at 60 units/s
if the gap were 3 frames	6.9	0.114
measured — 4 frames	9.1	0.152
if the gap were 5 frames	11.4	0.190
the port's authored value	12	0.200

The measured gap is ~9 units, and 12 is at or just past the top of the quantisation range. ⚠️ And the true black is shorter than this, not longer: the last publisher frame still carries alpha 7 and the first developer frame alpha 34, so both boundary frames contain some picture that this count treats as black.

🔴 RETRACTED: "the developer splash is ONE composited quad"

It is not. The three logos and their glows are drawn as separate quads, batched into a single draw call — indices=24 is six quads — and the log dumps only the first 8 vertices. The "525×259 quad at (378,155)" was min/max taken across two different quads: palogo_gamearts_eff (525×91 at 378,154) and palogo_seta_eff (262×108 at 512,306).

The port refuted it with arithmetic before I had checked: a 259-tall box cannot contain three logos spanning y 164…585, and palogo_anima alone starts 35 px below its bottom edge. They were right, and they were right to keep drawing three.

⚠️ The gap measurement is unaffected. Those glows are the first thing the developer splash draws (t0 a0 → t15 a255), so frame 130 is still the developer screen's first drawn frame, and frames 126–129 still submit nothing at all.

See ui-title-buildin-measured.md for the same trap producing a worse error on the title.

Is the gap declared anywhere? Not that I can find

• ❌ In the splash bundles. palogo_eff0.prm is one static keyframe (t0 a255). No fade quad, no gap.
• ❌ In the top-level header +0x08. It is a family constant — 300 for every title/splash entry in GP_TITLE, 60 for the loading bundles — and the slack against each bundle's last keyframe ranges from 12 to 226 units (the main menu's is 220, i.e. 3.7 s). It cannot be a declared gap.
• ❔ In the executable — not looked at. The corpus has the boot phase machine at this+132; whether a dwell or gap constant sits near it is untested. That is the next place, and I am naming it rather than claiming reach I do not have.

So the port is right to author this, and should author ~9 units rather than 12.

Reach

⚠️ One boot, one machine. The 4-frame count is quantised and the ±1 frame is the dominant uncertainty (6.9 – 11.4 units).

⚠️ The units-per-frame calibration assumes the guest's animation clock advances uniformly across the gap, which is the same assumption the rest of this corpus's frame→unit conversions make.

🔴 The instrument was perturbing what it measured

ui_draw_capture.sh taps Ⓐ whenever the screen changes a lot, to skip the attract movie. That trigger is also true while a boot splash is fading. A first run classified the publisher splash as a movie at t = 3 s, tapped through it, and the developer splash never appeared. Two knobs now exist and a boot run needs both:

• GRACE=1 — the fixed 8 s wait before arming meant an ARM=early capture always missed both splashes, which run at ~1.2 – 9.5 s of guest time;
• NOTAP=1 — no input at all.

Reproducing

GRACE=1 NOTAP=1 FRAMES=9000 MAXDRAWS=5000000 ARM=early \
  tools/re-capture/ui_draw_capture.sh 300 /tmp/uicap-boot