[Feature]: pass maxFramesInFlight through to Page.startScreencast #42809

🚀 Feature Request

Chromium 154 added maxFramesInFlight to Page.startScreencast, defaulting to 3. Playwright's Chromium delegate sends format, quality, maxWidth and maxHeight, so the parameter is not reachable through page.screencast.start().

What it costs. Recording a 2560×1600 page at 60 fps, measured on stock Chrome for Testing 154.0.8037.0, three interleaved repeats of the same run: at the default of 3 we capture 86.6 % of the frames Chromium reports it presented (89.5 / 82.2 / 88.0 %); at 12 we capture 98.8 % — 338 of 342, three times out of three. The loss is not evenly spread and it is visible in the finished video, not merely countable.

Why the userland route does not cover this one. We are aware of the position in #41007 — that recording knobs belong in userland via page.screencast.start({ onFrame }), and that shipping them constrains Playwright's own implementation. That reasoning holds for everything downstream of the frame: encoding, bitrate, container. This parameter acts upstream of it — it decides whether the browser hands the frame over at all — and onFrame is on the wrong side of that line. It is also not an API of Playwright's own making: Chromium exposes it, so passing it through does not lock in any implementation choice.

The design question we cannot answer for you. page.screencast covers three browsers and this is a Chromium term; Firefox and WebKit send { width, height, quality } at the same place. We would propose a generally-worded throughput hint that the other two ignore, but a browser-specific option, or simply a better default at large capture sizes, would all work for us. Which shape do you want?

We would like to implement it, docs and test included, once an issue is assigned.

Our current workaround is to drive the screencast over context.newCDPSession(page) ourselves, which works but means giving up page.screencast entirely.