sylpheed-port's caveat on my 1.07 units/frame: two strips agreeing to three
significant figures constrains the strips to each other, not the absolute rate,
because both ratios come from one capture under one fps assumption. They are
right and I could not remove it. Recording the three attempts and why each fails,
since a closed route is worth as much as an open one.
Route 1, compare the leaf to a TOP-LEVEL clock in the same capture so fps cancels:
not available. On a settled title nothing top-level moves -- that is what settled
means -- and every varying quad in the capture is a leaf. The plate looked like a
candidate (538x76, clean ~56-frame pulse) but build 2's ptbtn00 is a one-shot fade
at t=0,214,236,238,244; the repeating pulse comes from its own nested .rat.
Route 2, fit the same strips in the transition captures, which DO carry a
top-level clock (the fade quad, 8 declared units at 2.0 units/frame). The strips
are present but the fits are not measurements: rms residuals of 26.70 and 16.75 px
against 147 px of travel, versus 3.59 px against 627 px in titledraw2. Scatter,
not a line. The apparent disagreement between captures is a NON-measurement, and
quoting 1.94 or 3.57 as a second sample would have repeated the 6-7 px/frame
eyeball error one message after withdrawing it.
Route 3, read fps from the emulator's own log: not printed.
So 1.07 rules out a per-record quirk and does not pin the absolute rate. The test
that would is measuring the same strips at a deliberately different emulator frame
rate -- unchanged px/frame means frame-locked, scaling with 1/fps means wall time.
Not run.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
10b0dbe5c4