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

re: the long capture ran and fell 32% short -- sized the next one from measurement

Browse Source 
Attempted the capture this page named: FRAMES=8000, MAXDRAWS=400000, 700 s.
Reached frame 5954, still in the movie, zero UI quads after it.

Neither cap fired -- 24 213 draws of a 400 000 cap, 5954 frames of 8000 --
so it ended on the script's wall-clock timeout and nothing about the method
is wrong. It needs a longer window, not a different approach.

Sized from what this run measured rather than guessed: ~460 presents for
the splashes, a 137.714 s movie at 30.000 fps from the disc = 4131 decoded
frames, 2 presents per decoded frame measured, so ~8700 presents to clear
the movie. This reached 5954, about 68%, at ~22 presents/s armed. So
FRAMES=9000 and a timeout of at least 1200 s.

Also noting a saving I did not take: the h= content hash reads guest memory
for every sampled texture and the movie binds three planes per draw, but
the clock-origin measurement needs vertex alpha and not hashes. That field
is unconditional in canary-patches/0004; putting it behind its own cvar
would make this run materially faster.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
This commit is contained in:
sylph-decoder
2026-09-01 20:09:34 +00:00
parent e354e11f4c
commit a7013a8fe1
1 changed files with 37 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

37
docs/re/clock-origin-blocked-boot-has-no-title.md
View File

@@ -73,6 +73,43 @@ it, which these untapped runs do not. Whether the boot title and the post-movie
title are the same screen with the same clock is **not established**, and the
origin may differ between them.
## The long capture was RUN, and it is still short — with the numbers to size the next one
Option 2 above was attempted this iteration: `FRAMES=8000 MAXDRAWS=400000`, 700 s.
```
frames captured 0 .. 5954
last movie luma frame 5954 <- still in the movie at the end
UI quads after it 0
draws logged 24 213 of a 400 000 cap
```
**Neither cap fired.** The run ended on the script's **wall-clock timeout**, not on
frames or draws, so the fix is simply a longer window — nothing about the method
is wrong.
Sizing it from what this run measured rather than from a guess:
| | |
|---|---|
| presents consumed by the two splashes | ~460 |
| movie length ⟨disc⟩ | 137.714 s at 30.000 fps = **4 131 decoded frames** |
| presents per decoded frame ⟨capture⟩ | **2** |
| ⇒ presents to the end of the movie | ~**8 260** + 460 ≈ **8 700** |
| reached here | 5 954 (~**68 %**) |
| achieved rate | ~22 presents/s armed |
| ⇒ armed seconds needed | ~**400 s**, plus boot |
**So: `FRAMES=9000`, timeout ≥ **1200 s**.** 700 s was not enough and 8000 frames
would have been.
📌 One saving available: the `h=` texture content hash reads guest memory on every
sampled texture and the movie binds three planes per draw. **The clock-origin
measurement needs vertex alpha, not texture hashes**, so a build without that field
would run materially faster. The field is currently unconditional in
`tools/canary-patches/0004`; putting it behind its own cvar is the obvious
improvement and is not done.
## Reach
⟨capture⟩ ×3, one machine, English locale, `NOTAP=1`, 600 presents. The negative