🚀 Feature Request
I'm running multiple Playwright browser contexts concurrently, using page.screencast.start() to capture real-time frames and stream them as a "live view" (think: headless browser farm + dashboard preview).
In this use case:
- 1–5 fps is more than enough for human viewing
- But
page.screencast currently emits frames at a fixed (high) rate internally
- With N browsers × default FPS, CPU usage becomes the bottleneck long before network/bandwidth
There's no way to tell the browser "don't capture 25fps, I only need 5".
Example
No response
Motivation
We run multiple Playwright browser contexts concurrently to stream real-time browser views (browser farm / dashboard preview).
page.screencast.start()currently captures frames at a fixed high frame rate. In our live-view scenario, 1–5 fps is sufficient, but we cannot configure this limit. As a result, CPU usage scales linearly with the number of tabs—even though most frames are never visually meaningful to the viewer.
This makes screencast impractical for multi-browser deployments due to unnecessary CPU overhead.
🚀 Feature Request
I'm running multiple Playwright browser contexts concurrently, using
page.screencast.start()to capture real-time frames and stream them as a "live view" (think: headless browser farm + dashboard preview).In this use case:
page.screencastcurrently emits frames at a fixed (high) rate internallyThere's no way to tell the browser "don't capture 25fps, I only need 5".
Example
No response
Motivation
We run multiple Playwright browser contexts concurrently to stream real-time browser views (browser farm / dashboard preview).
page.screencast.start()currently captures frames at a fixed high frame rate. In our live-view scenario, 1–5 fps is sufficient, but we cannot configure this limit. As a result, CPU usage scales linearly with the number of tabs—even though most frames are never visually meaningful to the viewer.
This makes screencast impractical for multi-browser deployments due to unnecessary CPU overhead.