1850754 - Video with rounded corner does not overlay on Linux

Status: RESOLVED DUPLICATE of bug 1849680

(Core :: Audio/Video: Playback, defect)

Description

[David Turner]

Attachment: about_support

Steps to reproduce:

• Make a page with the below HTML, pointing at any MP4 video file
• Set gfx.webrender.debug.picture-caching to true
• Load the page and play the video

<div style="overflow: hidden; border-top-left-radius: 12px">
<video controls><source src="whatever.mp4" type="video/mp4"></video>
</div>

I can reproduce this on Debian 12, x86 and aarch64, Wayland and X11. about:support is attached.

Actual results:

• Picture tiles which overlap with the video are constantly dirtied
• With a weak GPU (e.g. raspberry pi 4), 30fps video renders at about 10fps or lower

Expected results:

Picture tiles should not be dirtied because of video playback. If I remove the border radius then playback performance on this system is fine.

Comment 1

[Jeff Muizelaar [:jrmuizel]]

Is performance bad if you keep gfx.webrender.debug.picture-caching = false?

Comment 2

[David Turner]

Yes, and if I remove the rounded corner then performance is fine even with picture-caching=true.

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Audio/Video: Playback' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 4

[Jeff Muizelaar [:jrmuizel]]

Can you get a profile with rounded corners and gfx.webrender.debug.picture-caching = false?

Comment 5

[David Turner]

Symbolicating takes ages for me (Firefox's builtin symbolication doesn't work with Debian dbgsym packages so I have to use samply) but here is a profile with partial symbols, which is enough to get a reasonable idea of what's going on: https://share.firefox.dev/3YV6R0C . I'll upload the profile again when symbolication finishes.

Most of the time goes into eglSwapBuffersWithDamageCommon in libEGL_mesa.so.0. I assumed the problem was simply this platform being so memory-bandwidth and/or GPU limited that it couldn't keep up with all the extra pixel-shuffling required to render 720p60 through the normal (non-overlay) WR pipeline. But if there is something fixable here then it would be great to know.

Comment 6

[Jeff Muizelaar [:jrmuizel]]

How much memory bandwidth does the raspberry pi have?

Comment 7

[David Turner]

Measured values are around 4GB/s, which I guess shouldn't be limiting on 720p60, though there's some extra colour-space conversion going on for the GPU to work on the textures.

Here's the profile after symbolication: https://share.firefox.dev/47V1ySX

Comment 8

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:jimm, could you have a look please?

For more information, please visit BugBot documentation.

Comment 9

[Jeff Muizelaar [:jrmuizel]]

(In reply to David Turner (away till 19th Sept) from comment #7)

Measured values are around 4GB/s, which I guess shouldn't be limiting on 720p60, though there's some extra colour-space conversion going on for the GPU to work on the textures.

Ok yeah, to make progress on this we'll need to better understand what the GPU is spending it's time doing. You wrote earlier that TIME_ELAPSED queries are not implemented. Has that changed? Is there an open issue about implementing them? Are there other tools for digging into GPU performance on the RaspberryPi?

Comment 10

[Glenn Watson [:gw]]

How is the performance now that the support for underlays with rounded corners has landed in nightly?

Comment 11

[David Turner]

I've just run a test on Raspberry Pi 4 with latest FF nightly playing a 1280x720 30fps h.264 video. Performance with rounded corners with the new fix is very slightly worse than without rounded corners but very close, and dramatically better than without the fix. I'm happy to close this issue now.

• With rounded corners, without the fix from Bug 1849680, presented FPS 9
• With rounded corners, with the fix from Bug 1849680, presented FPS 26
• Without rounded corners, presented FPS 28

Some time in the past few weeks v4l2 decode seems to have broken in nightly which is why even without rounded corners we're not quite hitting the full 30fps, I will investigate this separately.

Jeff: Sorry I forgot to get back to you. I haven't managed to get time-elapsed-queries implemented yet but this and other gfx performance debugging is something I'm looking into, so fingers crossed I'll make some progress there soon.

Comment 12

[David Turner]

Disregard the comment about V4L2 being broken, it's actually working fine, I got confused because some of the logging changed. I've done some more tests and with the fix there is still a consistent drop of 1-2 FPS when enabling rounded corners, but this seems ok to me.