- From: Tristan Fraipont via GitHub <sysbot+gh@w3.org>
- Date: Sat, 20 Nov 2021 02:49:30 +0000
- To: public-webrtc-logs@w3.org
It seems that implementations currently read >The requestFrame() method allows applications to manually request that a frame from the canvas be captured and rendered into the track. as saying "Set *this*'s `[[frameCaptureRequested]]` to `true`". Given that to actually "render" a new frame to the track, `captureStream` says that we need both `[[frameCaptureRequested]]` and an undefined "canvas is painted" event, this method actually fails its goal: > Applications that depend on tight control over the rendering of content to the media stream can use this method to control when frames from the canvas are captured. Both [Firefox](https://bugzilla.mozilla.org/show_bug.cgi?id=1613602) and [Chrome](https:/crbug.com/1047984) do render half-baked frames when we do use `captureStream(0)` + `requestFrame()`, Firefox because they wait for the next painting frame of the event loop before actually capturing the canvas frame, Chrome ... for more obscure reasons(?). To avoid this, `requestFrame()` should explicitly capture the canvas frame like any other API does (`drawImage()`, `toDataURL()`, `createImageBitmap()`, etc.), that is to capture it synchronously and push it to the track directly. -- GitHub Notification of comment by Kaiido Please view or discuss this issue at https://github.com/w3c/mediacapture-fromelement/issues/28#issuecomment-974580904 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Saturday, 20 November 2021 02:49:32 UTC