From 1538c3e33323c4adc8471cf454df39c8aa9a1785 Mon Sep 17 00:00:00 2001 From: sylph-decoder Date: Sun, 30 Aug 2026 17:03:15 +0000 Subject: [PATCH] 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) Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v --- docs/re/data/title-sweep-drawn-at-rest.txt | 41 ++++++++++++++++++++++ tools/re-capture/title_draw_capture.sh | 14 +++++++- 2 files changed, 54 insertions(+), 1 deletion(-) diff --git a/docs/re/data/title-sweep-drawn-at-rest.txt b/docs/re/data/title-sweep-drawn-at-rest.txt index 8a95d107..05c53384 100644 --- a/docs/re/data/title-sweep-drawn-at-rest.txt +++ b/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. diff --git a/tools/re-capture/title_draw_capture.sh b/tools/re-capture/title_draw_capture.sh index 1e6973b3..ffc926ac 100755 --- a/tools/re-capture/title_draw_capture.sh +++ b/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"