Frame recording with WebRender captures a high amount of screenshots on pages with videos
Categories
(Core :: Graphics: WebRender, defect, P4)
Tracking
()
People
(Reporter: mstange, Unassigned)
References
(Blocks 1 open bug)
Details
The frame recording API tries to only capture compositor frames during which a new content paint made it to the screen. However, the WebRender implementation of frame recording tries to make this distinction by checking whether any non-root pipelines have updated their epochs... and with WebRender, each video has its own pipeline which updates as the video plays new frames.
As a result, pages like cnn.com capture a ton of frames. cnn.com usually has videos below the fold. So we capture a ton of identical browser screenshots, at ~30fps.
|
||
Comment 1•4 years ago
|
||
I assume the frame recording API you're referring to is the one used by the Firefox profiler.
Assigning this S4 since it doesn't affect ordinary users. I'm not sure how we can reflect the importance of tools used by Mozilla developers and Firefox bug reporters.
|
||
Comment 2•4 years ago
|
||
It's actually the composition recorder API, which is used by Browsertime to do performance testing (and exposed via windowUtils.{start,stop}CompositionRecording()), but it is does not affect regular users.
|
Reporter | |
Comment 3•4 years ago
|
||
I thought a little about how to fix this.
My initial idea was to use the payloads, i.e. check for an eContentPaint payload, so that this would use the same manner of detection as non-WebRender. However, the payloads are kept on the compositor thread, and the recording needs to be done on the renderer thread. The pending payloads are stored on the WRBP for the tab in its mPendingTransactionIds queue, and each set of payloads is identified by its WR epoch. (The WR epoch is a pipeline-local counter that increments with every display list (?)). When a frame is rendered, the pipeline info contains the WR epoch for every pipeline that was included in the frame. So in theory, we could look up the payloads for that epoch at that point - if it weren't for the fact that we're on the wrong thread.
The other approach I investigated was to check, on the compositor thread just before the frame build is triggered, whether this frame build will include a content paint. Then that information could be forwarded to the renderer thread via IncPendingFrameCount. However, at the point where the compositor thread triggers the frame build, it does not know the WR epochs and pipelines that the generated frame is going to contain. So this doesn't work either.
Description
•