Sylpheed/docs/re/structures/ui-title-buildin-measured.md

The title's build-in, measured in the guest's own draw stream

Classification: measured. Xenia Canary, ui_draw_capture.sh ARM=early FRAMES=9000, 2026-08-29. Evidence: title-glow-alpha-per-frame.csv — the per-frame series the numbers below come from. (The 7 MB raw draw log is a scratch capture and is not committed.)

What this tests

ui-settle-time.md decodes the title's light arc as five staggered two-frame flashes (ptlogo_back2eff1…eff5) that fire around t54–66 and are gone by t110, with ptlogo_back2eff and ptlogo_back2 holding for the rest of the screen. That decode was confirmed only against a settled frame: posing at the settle time matched the console, which shows the end state is right and says nothing about whether the flashes ever happen.

ui-record-loop-length.md decodes the PRESS Ⓐ glow as a 120-unit cycle containing a 105-unit ramp that peaks at alpha 80.

Both are predictions about the running game. This is the run.

🔴 First, the trap that nearly produced a false negative

The obvious instrument — match a bound texture's dimensions to a decoded sprite's — does not work, and fails silently in both directions.

A first pass reported that none of the five flashes are ever drawn. It also reported ptbase2 (640×360) and pteff04 (1280×720) drawn during frames 75–105. Both were wrong. Those frames are the intro movie: four full-screen quads per frame sampling a pair of 640×360 planes and a 1280×720 target — a video decode whose plane sizes happen to collide with two sprite sizes. And the flashes were missing because the title's sprites sample large shared texture pages, so the bound texture identifies a page, not an element.

Canary's own capture code says so in a comment, and the corpus had already recorded that the settled title's textures are all 1280×768. The identity of a 2D draw here is its vertex geometry, not its texture. Re-run against the quad rects, everything appears.

The structure of the title in the draw stream

frames	draws/frame	what
2–105	3–5	splashes, then the intro movie
107	27	a transition frame — see the caveat below
109–167	6 → 14	the build-in
168–1217	10–11	the settled title
1218–	4–5	back to the attract loop

The settled screen is 10–11 draws that never name a sprite. A capture armed at the title therefore sees nothing — which is why ARM=early exists.

⚠️ What frame 107 is, is NOT established. An earlier version of this page called it "the title composited, once". It is a 27-draw spike sitting between the movie's last frame (105) and the title's first (109), it binds no texture at all, and only 4 of its 27 draws log any geometry. It marks the transition; calling it the composite was an over-read. (The regression below independently puts t=0 at frame 106.1, which is consistent with the title's clock starting here — but that is a fit landing nearby, not evidence about what the 27 draws do.)

The flashes are real, and they are transient

Matching quads by design-space rect over frames 100–260, and converting frames to keyframe units with 2.346 units/frame — derived from the glow's period alone, a different element, taking the composite spike (frame 107) as t=0:

element	drawn in frames	→ t units	decoded
ptlogo_back2eff1	130–131	54.0 – 56.3	flash, peak t54–56 ✅
ptlogo_back2eff2	133	61.0	flash, peak t58–60
ptlogo_back2eff3	never	—	flash, peak t62–64 ⚠️
ptlogo_back2eff4	133–135	61.0 – 65.7	flash, peak t~64 ✅
ptlogo_back2eff / eff5	134–260	63.3 – …	255 at t64–66, holds ✅
ptlogo_back2	134–260	63.3 – …	255 at t80, holds ✅
ptlogo1	125–148	42.2	stops moving at t42 ✅

The flashes fire inside a six-frame window and are absent from every one of the other 155 frames sampled. The two holders are present continuously from frame 134 onward. That is the decoded mechanism, observed.

🔴 The game does not draw ptlogo_back2eff3

Reproduced over two title entries, 5 800 frames apart, in one run. The disc declares ptlogo_back2eff3 — alpha 0 at t58, 255 at t60–62, 0 at t64, at (788, 117), sprite 408×203 — and the running game never submits it.

The wipe family is right-aligned: eff2 938+258, eff3 788+408, eff4 447+749, eff5 64+1133 all end at x≈1196. It is a left-growing wipe in four widths, and the game draws three of them.

element	width	draws across both build-ins	expected at ~2.23 units/frame
eff1	167	4	~5
eff2	258	3	~5
eff3	408	0	~5
eff4	749	6	~5

⚠️ An earlier version of this page called this a sub-frame phase effect. That was wrong and is withdrawn. Three explanations were tested and all fail:

• Sampling phase. eff3's non-zero window is t ∈ (58, 64) — six units, against a step of 2.23 units per presented frame. A window wider than the step cannot be missed: at least two frames must land inside it, and frames 133 (t = 60.1) and 134 (t = 62.3) do. Both draw eff2 and eff4; neither draws eff3.
• A draw the log cannot see. Exactly 2 draws per frame carry no geometry, on all 932 settled title frames — always the same full-screen-triangle shader (prim=8 indices=3, vs=0x72CBCAA6A7984111), present on frames where no wipe element is active at all. eff3 cannot be one of them.
• A bad position guess on my side. Dropping the position entirely and searching every quad submitted anywhere on screen during both build-in windows: zero have a width within ±30 of 408. The width spectrum jumps straight from 262 to 748.

❔ Why the game skips it is not established. Nothing in its element record distinguishes it — same kind (0x0), same keyframe shape, same u4/u8, same scale, as eff2 and eff4 either side of it.

🔴 For the port: you draw eff3 at t=60–62 and the console does not. That is one extra frame of wipe, at the widest-but-one step. It is small, and it is real.

🔴 A second thing this page previously claimed, also withdrawn: that a port drawing all five flashes shows "more sweep than the console". There is no evidence for that. The port draws them sequentially at their declared times, never more than two at once, which is what frames 131–135 above show the game doing. The pile-up worth warning about was the rest() bug, and that is fixed.

⚠️ What a frame-by-frame comparison of the build-in WILL show, and it is not a defect on either side. The game's timeline is 60 units/s against a 30 Hz present, so 2 units per submitted frame; this capture ran at 2.231 units per presented frame. A 2-unit flash peak therefore gets about one frame here and would get more on a faster present. A build-in compared frame-by-frame against this capture will disagree about which flashes appear in which frame, and neither side is wrong. The settled comparison is unaffected — at t=198 none of the five is drawn.

The glow's ramp, read out of the guest

The plate glow's quad carries a per-vertex colour whose alpha is the element's fade alpha, so the ramp can be read directly rather than inferred from pixels.

• Observed alpha range: 0 … 80. Decoded peak: 80. Exact, and not fitted.
• ⚠️ This identity holds for the glow and does NOT generalise. Read the same way, eff4 gives 255 at frame 133, 127 at 134 and 254 at 135 — non-monotonic, so a per-vertex alpha is not simply the element's fade alpha for every element. The glow's agreement (peak exactly 80) is evidence for the glow, not a decoded rule about vertex colour.
• Period: 51.158 presented frames, from the first to the last of 20 consecutive cycle starts (individual periods 49–53).
• The draw is omitted entirely while the glow is dark — which is what the 11↔10 draw alternation in the settled title is.

Fitting the decoded 8-keyframe ramp to the 972 measured frames, with one disclosed free parameter (a constant phase offset):

curve	RMS residual, alpha levels
the decoded ramp, phase +2.25 units (= +0.96 frames, sub-frame)	13.16
the decoded ramp, no phase fit	13.68
a symmetric triangle of the same period and peak	15.73
flat at the mean	31.13
🔴 the decoded ramp REVERSED	38.18

The reversal control is the one that matters: if the shape carried no information, forwards and backwards would fit equally. They differ by 2.9×, so the measured ramp has the decoded ramp's asymmetry — fast rise, slow fall — in the decoded direction.

⚠️ The +0.96-frame phase is the expected bias, not a correction: a cycle start is detected at the first frame with a non-zero alpha, and the decoded curve leaves zero part-way through a frame.

Two entries, different phases

The attract loop returns to the title, so one capture contains two build-ins (frames 119–1220 and 5942–7025). They are the same animation and are not frame-aligned: aligning them on eff1's first frame, only 4 of 46 frames have an identical quad list, and the draw-count sequences drift by a frame partway through.

That is what makes the eff3 result robust rather than weaker. Two independent samplings of the same animation, at different phases, both miss it.

⚠️ Only the first entry has the 27-draw frame; the second goes straight from 3–6 draws into the build-in. Whatever frame 107 is, the re-entry does not repeat it.

Reach and what is not settled

⚠️ One run, one machine. ~2.23 units per presented frame is this run's pacing, not a property of the game — the game's own quantum is 2 units per submitted frame (ui-keyframe-time-unit.md). The internal ratios are what transfer.

✅ A validation worth stating: the fit recovers t=0 on its own. Regressing the observed frame of five events against their declared keyframe times (residuals ≤ 0.9 frames over t = 42…138) gives a slope of 2.231 units/frame and an intercept at frame 106.1 — and the composite spike, which was not part of the fit, is frame 107.

❔ The glow's period implies a 114-unit cycle at that slope, against a declared 120. The dark-fraction test below settles 120 against 105 without any calibration, but the 5 % gap in the period is unexplained.

❔ The absolute frame rate of this run was not measured — Canary logged no fps and the log has no timestamps — so nothing here is stated in seconds. It did not need to be: every comparison above is a ratio of measured quantities.

❔ ptlogo_tm was never matched. At 37×17 it is below the rect tolerance used; absence here is not evidence.

⚠️ eff5 and ptlogo_back2eff are the same rect at the same position and were not separated. Distinguishing them needs the per-vertex alpha, which the decode says differs — not attempted.

Reproducing

FRAMES=9000 MAXDRAWS=5000000 ARM=early tools/re-capture/ui_draw_capture.sh 900 /tmp/uicap
python3 tools/re-capture/buildin_timeline.py /tmp/uicap/xenia_re_ui_draws_01.log