Two runs per arm, about 81,000 frames each, order A B C C B A:
A step 1 as is 0.90% late, 20.1 per 10k two+ refreshes late
B switch_interval_ms 1 0.78% late, 15.8 per 10k
C prefetch_gate 0.60% late, 2.5 per 10k
No freezes in any arm, and the next group was ready at every strip
extension, so parking the prefetch thread (3-6s per 8-minute run) cost
nothing visible. The gate is now on unless vegas_scroll.prefetch_gate is
false; on a stock binding it cannot work and says so at INFO once a run
rather than warning on every install. switch_interval_ms stays off.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The render thread spends most of each refresh in SwapOnVSync with the GIL
released, then needs it back the moment the swap returns. With plugin
rendering on the prefetch thread, it often has to wait for it -- behind
bytecode for up to the switch interval, behind a GIL-holding C call for as
long as that takes -- and hdpi's late frames of 2-5 refreshes went up.
src/common/render_gate.py opens a window around each swap, up to just
before the refresh the swap will return on, and a profile hook on the
prefetch thread parks it outside that window. It is never parked holding a
lock the render thread also takes (the Vegas buffer, cache and state
locks, logging, threading, importlib, the cache), never when no frame has
been swapped for 50ms, and never for more than 50ms at a time.
Off by default and ignored on a binding that keeps the GIL in
SwapOnVSync, where the window would never let the prefetch run.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
