re: the leaf is NOT frame-locked -- and a residual gate disqualifies half my fits

The frame-rate test sylpheed-port and I agreed was the only clean route left.
Same strips, same screen, --framerate_limit=15 against the default. The limit
demonstrably took effect: the title settled at 862 s against 241 s.

First, a gate this work should have had from the start. A slope is only a rate if
its residual is random, so count sign changes in the residual:

  default   1299x1303  -4.348  rms 3.33  43/111  OK
             883x1134  +4.284  rms 3.08  21/76   SYSTEMATIC
             890x1134  +4.284  rms 3.19  15/54   SYSTEMATIC
  limit 15  1299x1303  -2.032  rms 1.51  44/83   OK
             883x1134  +2.003  rms 1.12  36/61   OK
             890x1134  +1.999  rms 0.74  12/37   SYSTEMATIC

So one of the two strips I quoted as "agreeing to three significant figures"
FAILS the linearity gate at default fps: that agreement was between a rate and a
slope through a curve. The port had already caveated the claim for a different
reason; this weakens it further from my own side.

The result, on the one group passing the gate at both settings: -4.348 px/frame
at default against -2.032 at limit 15, a ratio of 2.14.

THE LEAF IS NOT FRAME-LOCKED. A fixed number of units per submitted frame
predicts px/frame unchanged; it changed by 2.14x. Dead.

A simple wall-clock model is dead too, in the other direction: fewer frames per
second means more wall time per frame, so a time-driven leaf should move MORE
px/frame at a lower limit. It moved LESS. Neither model fits and I have no third.

Reach: the effective frame rate was NOT measured. The timing instrument I added
polls for the capture log, which is created when the capture is ARMED rather than
when it finishes, so it reported 0.728 s and is void. The 3.6x boot slowdown says
the limit took effect, not that fps went 28 -> 15. The RATIO is measured; the
absolute rate still is not.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v

docs/re/data/title-sweep-drawn-at-rest.txt

@@ -109,3 +109,44 @@
 # at a deliberately different emulator frame rate -- if px/frame is unchanged the
 # leaf is frame-locked, if it scales with 1/fps the leaf runs on wall time. That
 # has not been run.
+
+################################################################################
+# THE FRAME-RATE TEST. 2026-08-30. The one clean route left.
+#
+# Same strips, same screen, two emulator frame rates. `--framerate_limit=15`
+# against the default. That the limit took effect is visible in the boot: the
+# title settled at 862 s against 241 s, 3.6x slower.
+#
+# ⚠️ FIRST, A GATE THIS SHOULD HAVE HAD FROM THE START. A slope is only a rate if
+# the residual is random. Counting sign changes in the residual:
+#
+#   default fps   1299x1303  slope -4.348  rms 3.33  sign-changes 43/111  OK
+#                  883x1134  slope +4.284  rms 3.08  sign-changes 21/76   SYSTEMATIC
+#                  890x1134  slope +4.284  rms 3.19  sign-changes 15/54   SYSTEMATIC
+#   limit 15      1299x1303  slope -2.032  rms 1.51  sign-changes 44/83   OK
+#                  883x1134  slope +2.003  rms 1.12  sign-changes 36/61   OK
+#                  890x1134  slope +1.999  rms 0.74  sign-changes 12/37   SYSTEMATIC
+#
+# 🔴 So one of the two strips I quoted as "agreeing to three significant figures"
+# FAILS the linearity gate at default fps. The agreement was between a rate and a
+# slope through a curve. sylpheed-port had already caveated that claim for a
+# different reason; this weakens it further, from my own side.
+#
+# 📌 THE RESULT, on the one group that passes the gate at BOTH settings:
+#
+#   default          -4.348 px/frame
+#   framerate_limit=15  -2.032 px/frame        ratio 2.14
+#
+# ✅ **THE LEAF IS NOT FRAME-LOCKED.** A fixed number of units per submitted frame
+# predicts an unchanged px/frame. It changed by 2.14x. That hypothesis is dead.
+#
+# 🔴 AND A SIMPLE WALL-CLOCK MODEL IS DEAD TOO, in the other direction. Fewer
+# frames per second means more wall time per frame, so a time-driven leaf should
+# move MORE px/frame at a lower limit. It moved LESS. Neither simple model fits
+# and I do not have a third.
+#
+# ⚠️ REACH. The effective frame rate was NOT measured -- the instrument I added to
+# time the capture window is broken: it polls for the log file, which is created
+# when the capture is ARMED rather than when it completes, so it returned 0.728 s.
+# The 3.6x boot slowdown says the limit took effect; it does not say fps went from
+# 28 to 15. So the RATIO is measured and the ABSOLUTE rate still is not.

tools/re-capture/title_draw_capture.sh

@@ -20,6 +20,7 @@ OUT="${1:-/sylph-home/re/titledraw}"; mkdir -p "$OUT"; rm -f "$OUT"/xenia_re_ui_
 ensure_single_emulator || exit 3
 ( cd "$OUT" && nohup run-canary --mem_watch=false --log_ui_draws=true \
     --ui_draw_capture_frames="${FRAMES:-150}" --ui_draw_capture_max=400000 \
+    --framerate_limit="${FPSLIMIT:-0}" \
     --logged_profile_slot_0_xuid=B13EBABEBABEBABE \
     >"$OUT/canary.stdout" 2>"$OUT/canary.stderr" & )
 sleep 10
@@ -28,9 +29,20 @@ until xdotool search --name "Xenia-canary" >/dev/null 2>&1; do sleep 1; done
 win="$(xdotool search --name "Xenia-canary" | tail -1)"
 python3 "$SD/wait_plate_pulse.py" 900 || exit 1
 xdotool windowactivate --sync "$win"; sleep 1
+# Time the capture window so the run MEASURES its own frame rate instead of
+# assuming it. Without this, px/frame cannot be turned into px/second and the
+# leaf-rate question stays fps-bound -- which is exactly the caveat that closed
+# three earlier routes.
+t0=$(date +%s.%N)
 xdotool key F10; sleep 0.6
 xdotool mousemove 900 400 click 1
-sleep 12
+for _ in $(seq 1 400); do
+  ls "$OUT"/xenia_re_ui_draws_*.log >/dev/null 2>&1 && break
+  sleep 0.1
+done
+t1=$(date +%s.%N)
+echo "CAPTURE-WALL-SECONDS $(awk -v a="$t0" -v b="$t1" "BEGIN{printf \"%.3f\", b-a}")"
+sleep 6
 grep -i "UI-CAP" "$OUT/canary.stdout" | tail -3
 ls -l "$OUT"/xenia_re_ui_draws_*.log 2>/dev/null || echo "NO CAPTURE LOG"
 echo "TITLE DRAW CAPTURE DONE"