Warm the frame recorder before hiding the window at recording start
The first screenshot of a session was late while every later one was fine. Cause: on 'Start recording' the window hid first and the capture backend started warming up after — creating worker, getUserMedia, first frame takes ~1s. A click in that gap found no buffered frame and took the post-click fresh shot. armRecording() now warms the recorder while the window is still visible and only hides once frames are buffering (with a brief post-hide settle so the first frame shows the user's screen, not the dismissed app window). Verified end to end with a new self-test scenario that clicks 250ms after start: the first click is now served a pre-click frame instead of a post-click shot. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
@@ -30,6 +30,12 @@ Keep-a-Changelog conventions; versions follow semver.
|
||||
cadence was tightened to 50ms so a frame near that target always exists.
|
||||
The lead is a preference, not a gate: selection falls back to the newest
|
||||
frame still before the click, so it never forces a post-click screenshot.
|
||||
- The frame recorder now warms up *before* the window hides at recording
|
||||
start, instead of after. Previously the first click of a session could
|
||||
beat the ~1s warmup and fall back to a post-click shot — "the first
|
||||
screenshot is late" — while every later click was fine. Now frames are
|
||||
buffering by the time the window tucks away, so the first click is
|
||||
served a pre-click frame like the rest.
|
||||
|
||||
### Fixed
|
||||
|
||||
|
||||
Reference in New Issue
Block a user