[Bug]: Agent preview recordings drop ~40% of frames at 1600×900 and come out blurry (frame-numbered repro)#24979

Summary

Agent recordings (preview_recording_start / preview_recording_stop) skip more frames the bigger the viewport is, and the text comes out soft and blocky. I tested a minimal page that numbers each of its frames on screen. At 1280×800, 91–97% of the frames the page drew made it into the video. At 1600×900 only 58–65% did. This is a separate problem from #19442 / #23895 (the 30 fps cap). It shows up on a build that already includes #23895.

Environment

• T3 Code Nightly 0.1.3-nightly.20261025.3682 (Electron 44.9.3, Chrome 152.0.7977.167), macOS 27.0 on Apple Silicon
• Recording frame-rate setting: not changed from the default

Repro

1. Serve the attached index.html locally. It draws a 12-bit barcode holding the page's requestAnimationFrame count in the top-left corner. Its runTest() runs: 2 s idle, then 3 s where the page changes every frame, then a 3 s eased scrollTo driven by requestAnimationFrame, then 2 s idle.
2. preview_open the page, then preview_resize it to freeform 1600×900.
3. Run preview_recording_start, then preview_evaluate("runTest()"), then preview_recording_stop.
4. Run python3 decode.py <recording.mp4>. It reads the barcode from every encoded frame and reports which page frames were captured.

Results

In both runs the page drew all 360 of its frames. The page's own frame log (window.__frames) shows the longest gap between frames was 17.7 ms.

• The attached crop from mid-scroll at 1600×900 (scroll-frame-1600.png) shows smeared text and mush where the diagonal stripes should be, even though the frame is captured at 2× scale.
• On a real app (a Next.js dashboard streaming an AI response, 1600×900), only 11 distinct frames made it into the video during a 1.6 s eased scroll (about 7 fps). The same flow recorded with ffmpeg avfoundation at 60 fps captured 96.
• While nothing changes on the page, the gap between video frames reaches 3–4 s. Frames are only produced when the page repaints, so the output has a variable frame rate. That's expected, but the low average bitrate of a long, mostly idle recording hides how few bits each moving frame gets.

Likely cause (from reading main)

• In apps/server/src/preview/ServerBrowser.ts (around L1459–1500), each 2× JPEG frame from Page.startScreencast goes base64 through Playwright evaluate into a scratch page. There it is decoded with createImageBitmap and drawn to a canvas, and only then acked. maxFramesInFlight is not set, so the number of frames per second is limited by that round trip. The round trip gets slower as the frame gets bigger, which matches the 1280 vs 1600 results.
• The MediaRecorder bitrate (ServerBrowserPage.ts, w*h*frameRate*0.05) assumes frames arrive at a steady frameRate.
• #8839 fixed a similar screencast → canvas pipeline by switching to native tab capture, and the toolbar record button still uses that path.

Possible directions

• Allow more frames in flight, or ack before decoding.
• Send the frames as binary instead of base64 through evaluate.
• Use the native tab stream for tabs rendered in the desktop app.
• Encode at a constant frame rate by repeating the last frame while the page is idle.

Related: #19442, #23895, #8839, #15328.

Repro files (test page, decoder, both recordings, a mid-scroll frame) are attached in the first comment.