Replies: 2 comments
-
Yes. When using CanvasSource, Mediabunny relies on your manual loop (e.g., via requestAnimationFrame or setInterval) to capture frames and feed them into the recording output. Since hidden/inactive tabs inherently throttle such loops—especially requestAnimationFrame—you will experience reduced frame capture rates and choppy or incomplete recordings in the background. Mediabunny itself does not internally mitigate browser throttling. It assumes frame production continues as expected by the user’s code.Yes, that's a solid workaround. While Mediabunny doesn't handle throttling, you can mitigate it using a few well-known patterns: Visibility API (document.hidden / visibilitychange): Pause or slow your capture loop when the tab is hidden, then resume when the tab becomes visible again. OffscreenCanvas + Web Worker: Running your render loop inside a worker isn’t subject to the same throttling rules as the main thread. You can render frames off the main execution path and pass the pixel data or ImageBitmap to the main thread to feed into CanvasSource. Use MediaStreamVideoTrackSource when possible: If your use case involves screen recording or capturing a live source (like a canvas or webcam), Mediabunny’s MediaStreamVideoTrackSource piped from getDisplayMedia() or getUserMedia() is more robust and typically continues capturing smoothly—even when the tab is backgrounded. ere are some practical patterns that developers often employ for uninterrupted capture:
Technique | Pros | Cons
-- | -- | --
Visibility-aware loop | Simple to implement; stops when inactive | Still throttled when hidden unless paused aggressively
OffscreenCanvas in Worker | Bypasses main-thread throttling; smooth continuous rendering | More complex setup and data transfer overhead
getDisplayMedia() + MediaStreamVideoTrackSource | Native continuous capture, handled by browser | Less control over per-frame timing; not always suitable for custom rendering pipelines
|
Beta Was this translation helpful? Give feedback.
-
Good question. So, when you're rendering a canvas as fast as possible, you usually don't have a rAF or setInterval setup. Instead, you have a tight loop that cranks through the frames as fast as possible. So for those cases, it doesn't throttle. So, if this is an option, do that. But if this is not what you're asking about, and the rendering necessarily must be real-time (perhaps it responds to user input?), then you need a different solution. The classic trick here is to use setInterval but in a Worker, instead. So, spawn a Worker which does nothing but run a setInterval, and each time it ticks, it sends a message back to the main thread, waking it up and prompting it to render the next frame. This works, and never throttles even if the tab is in the background. No need for OffscreenCanvas or anything like that. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Hi 👋,
I’m exploring Mediabunny for recording a CanvasSource. One concern I have is hidden tab throttling in browsers where setInterval / requestAnimationFrame are heavily clamped when a tab is not visible.
👉 My questions:
If I use a regular with CanvasSource, will Mediabunny suffer from the usual throttling when the tab goes into the background?
Does Mediabunny internally mitigate this, or do I need to use OffscreenCanvas in a Worker to avoid the clamping?
Are there recommended patterns/examples for continuous recording of a canvas in hidden/inactive tabs (e.g., screen recording scenarios)?
Thanks a lot for building Mediabunny it looks like an amazing alternative to MediaRecorder
Beta Was this translation helpful? Give feedback.
All reactions