fabi/Sylpheed
1
0
Fork 0
Code Issues 9 Pull Requests Actions Packages Projects Releases Wiki Activity

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

Browse Source 
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
This commit is contained in:
sylph-decoder
2026-08-30 17:03:15 +00:00
parent f845dda9a5
commit 721de02723
2 changed files with 54 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -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.