1677892 - Fullscreen video stutters back and forth between two frames with EGL/Xwayland partial present

Status: RESOLVED MOVED

(Core :: Graphics: WebRender, defect)

Description

[Darkspirit]

Attachment: Bildschirmfoto von 2020-11-18 01-43-34.png

Gnome Xwayland, Debian Testing, Intel HD Graphics 630 (KBL GT2)
Mesa 20.2 supports swap_buffers_with_damage on X11 (DRI3). Debian Testing just got this version. (Ubuntu 20.10 has it, too.)

If the progress bar of a fullscreen Twitter video is hidden, the video repeatedly stutters back and forth between two frames.

Make this video fullscreen:
MOZ_X11_EGL=1 mozregression --launch 2020-11-16 --pref gfx.webrender.all:true -a https://twitter.com/dwnews/status/1328824233334628352

This bug does not occur with gfx.webrender.max-partial-present-rects:0.

---

MOZ_X11_EGL=1 mozregression --good 2020-09-16 --bad 2020-10-16 --pref gfx.webrender.all:true gfx.webrender.max-partial-present-rects:1 -a https://twitter.com/dwnews/status/1328824233334628352

15:54.10 INFO: Last good revision: ee7748232b6c7d7d73ec13e5a222e6a2fc83a882
15:54.10 INFO: First bad revision: 6265af1b66f3d39589035bba8a55770ba5fc306d
15:54.10 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=ee7748232b6c7d7d73ec13e5a222e6a2fc83a882&tochange=6265af1b66f3d39589035bba8a55770ba5fc306d

6265af1b66f3d39589035bba8a55770ba5fc306d Jamie Nicol — Bug 1575765 - Enable partial present for webrender on android. r=gw
3ee3485a78c1599ee6c8e9dba3b4fb02d87b1784 Jamie Nicol — Bug 1575765 - Implement KHR_partial_update for webrender. r=sotaro,jgilbert
5294a158e801856e522019782f1604fdfb87a131 Jamie Nicol — Bug 1656533 - Handle buffer ages other than 2 for EGL_EXT_buffer_age. r=sotaro,gw

I've added both bugs to "Regressed by", please remove the wrong one.

I could see another difference with Gnome Wayland's partial present debug mode (bug 1640858 comment 12):

• with last good, the video played in fullscreen without being red (no damage region?)
• with first bad, there was a red box of the size of the video, but left to the video. Attached image is an edited screenshot because it's not possible to make a screenshot of the red box. So the damage region is apparently just at the wrong position.

Comment 1

[Darkspirit]

This bug doesn't seem to occur on Gnome X11. The video has a transparent purple rectangle on top of it. (damage region painting: bug 1640858 comment 12)

Comment 2

[Robert Mader [:rmader]]

(In reply to Darkspirit from comment #0)

• with last good, the video played in fullscreen without being red (no damage region?)

I assume this is on Gnome 3.38. In that case, no red overlay implies fullscreen unredirection, e.g. the compositor directly flips the buffer without compositing, which is great for performance.

• with first bad, there was a red box of the size of the video, but left to the video. Attached image is an edited screenshot because it's not possible to make a screenshot of the red box. So the damage region is apparently just at the wrong position.

This is really odd. So there's no fullscreen unredirection and something is wrong with the damage region...

Comment 3

[Robert Mader [:rmader]]

It could be that you're running into this: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7033

Comment 4

[Darkspirit]

Yes, I have 3.38.1-2.

Comment 5

[Darkspirit]

(In reply to Robert Mader [:rmader] from comment #2)

I assume this is on Gnome 3.38. In that case, no red overlay implies fullscreen unredirection, e.g. the compositor directly flips the buffer without compositing, which is great for performance.

That still seems to be the case when playing a fullscreen video with Firefox' default video player UI. I can even hover or move the progress bar and nothing becomes red as long Firefox is fullscreen.

(Darkspirit from comment #1)

This bug doesn't seem to occur on Gnome X11. The video has a transparent purple rectangle on top of it. (damage region painting: bug 1640858 comment 12)

MOZ_ENABLE_WAYLAND=1 looks like X11. The video itself is red all the time.

Comment 6

[Robert Mader [:rmader]]

Ok, just tested myself and there seems to be something wrong with partial damage on X11. For me it's especially visible with the hamburger menu: it apparently often does not get damaged when hovering items, making it update super slow. Disabling partial damage makes fast again.

Comment 7

[Robert Mader [:rmader]]

Jamie, do you think you could have a look into what's wrong with partial damage on EGL at some point this cycle? Otherwise we'd have to disable it for X11/EGL again for the moment I think.

Comment 8

[Jamie Nicol [:jnicol]]

Jamie, do you think you could have a look into what's wrong with partial damage on EGL at some point this cycle?

I'm afraid I can't promise anything because I'm fairly rammed with android work. Especially if I can't reproduce myself. But I will try to help.

My hunch is that bug 1656533 regressed this. The buffer age is probably != 2 most of the time, so before that change we were doing full renders instead of partial ones. Although I guess it could have been bug 1575765 if mesa supports KHR_partial_update and there's a bug either in mesa or firefox.

I'm afraid I can't reproduce this. On Fedora 33 with Mesa 20.2.2.

How do I get the red square to show up?

Darkspirit, to confirm, you see this bug on XWayland only, and it works fine in Xorg and Wayland?

Robert, the problems you mention in comment 6, is that Xorg, XWayland, or both? And Wayland is still okay?

Comment 9

[Darkspirit]

(In reply to Jamie Nicol [:jnicol] from comment #8)

Although I guess it could have been bug 1575765 if mesa supports KHR_partial_update and there's a bug either in mesa or firefox.

Mesa doesn't seem to support it, I don't see it on about support.
Proprietary Nvidia does support it, but this bug only seems to occur on Xwayland which requires Mesa.

I'm afraid I can't reproduce this. On Fedora 33 with Mesa 20.2.2.

I'll also test Ubuntu later.

How do I get the red square to show up?

"Gnome Wayland's partial present debug mode (bug 1640858 comment 12)"
"(damage region painting: bug 1640858 comment 12)"

Darkspirit, to confirm, you see this bug on XWayland only

comment 1: "This bug doesn't seem to occur on Gnome X11."
I haven't tested KDE with and without compositing, XFCE, etc. yet.

and it works fine in Xorg and Wayland?

comment 9: "MOZ_ENABLE_WAYLAND=1 looks like X11. The video itself is red all the time."
This is a bonus bug about efficiency: From what Robert said there should be "fullscreen unredirection" (no red box). On Xwayland this was the case before the regression. I haven't checked this on X11 and Wayland yet.
comment 5: Firefox own video player UI still doesn't show a red box on Xwayland.

Comment 10

[Robert Mader [:rmader]]

Some notes already:

• mesa does support KHR_partial_update on some drivers, but it only targets tiled renderer GPUs, i.e. ARM socs. So that shouldn't interfere here.
• concerning fullscreen unredirection: it may or not work on Xwayland, depending if a matching format was chosen. Once Mutter supports atomic KMS (next version i.e. Gnome 40) it will reliably work. On Wayland it is blocked by bug 1668805 - I have a rough idea how it could be fixed, but it's quite adventurous.

Comment 11

[Robert Mader [:rmader]]

Interesting, so while I can very reliably reproduce this, it only happens on Xwayland (with EGL + partial damage). X11/GLX and Wayland are both fine. Apparently there's never ever damage submitted when hovering the hamburger menu - it only gets redrawn occasionally at around 1Hz here. I'll talk to Xwayland and Mesa devs, maybe there's nothing wrong with Firefox here. In the, EGL_KHR_swap_buffers_with_damage is super new on X11 and we are probably one of the first applications making extensive use of it :)

Comment 12

[Robert Mader [:rmader]]

Small update: I can only reproduce this on Mutter (3.36 - current master), but not on Weston. Jan, may I ask you if you can reproduce this on KWin?

Comment 13

[Jamie Nicol [:jnicol]]

Just cc'ing Andrew and Nical so this is on their radar, especially since we may need to make a call to disable partial present, or it may affect rolling out EGL etc.

Comment 14

[Robert Mader [:rmader]]

Ok, I'm now 90% certain that it's a bug in the (very new) X11 version of EGL_EXT_swap_buffers_with_damage in combination with the present extension. It also make sense that bug 1656533 made this appear - we usually have 4 buffers on X11, so previously we would fall back to full damage AFAICS (somewhere in mesa). If I disable the present extension in Xwayland things work just fine, with proper partial damage.

The good news is that this shouldn't affect users using mesa < 20.2 - and for those who do have it, we might be able to push out a fix in time for 85 (or 86 or so).

Comment 15

[Robert Mader [:rmader]]

Got a fix! It was Xwayland after all: https://gitlab.freedesktop.org/daenzer/xserver/-/commit/71c416d3b44014035785b9df66c5f6539d3e968e

Comment 16

[Darkspirit]

(In reply to Robert Mader [:rmader] from comment #6)

For me it's especially visible with the hamburger menu: it apparently often does not get damaged when hovering items, making it update super slow. Disabling partial damage makes fast again.

Confirmed on Xwayland.

(In reply to Robert Mader [:rmader] from comment #15)

Got a fix! It was Xwayland after all: https://gitlab.freedesktop.org/daenzer/xserver/-/commit/71c416d3b44014035785b9df66c5f6539d3e968e

Thank you! :)

---

Affected is EGL/XWayland with Mesa 20.2 (Debian Testing, Ubuntu 20.10).

• It will be fixed with xwayland 1.20.10. Debian Testing currently has 1.20.8. Ubuntu 20.10 has 1.20.9.
• This bug doesn't seem to occur if the video is 16:9 and fills the whole screen. That's also why I couldn't reproduce it with Firefox' own video player UI until now.

I'll needinfo myself and verify once I've got the update. The fix seems plausible.

Comment 17

[Andrew Osmond [:aosmond] (he/him)]

For shipping EGL purposes, is this something we should be checking for and blocking use of the extension?

Comment 18

[Robert Mader [:rmader]]

(In reply to Andrew Osmond [:aosmond] from comment #17)

For shipping EGL purposes, is this something we should be checking for and blocking use of the extension?

I don't think we'd want that, AFAIK it helps a lot with performance when e.g. watching fullscreen videos (zero copy flip). IMO what we could do is disabling partial damage for the X11/EGL case for another release or two (adding a extra pref for that time? We wouldn't want to disable it on Wayland).

I'd be quite optimistic that the fix will be available by the time 85 ships, but if Debian is still on 1.20.8, well, it may take a bit of time.

Comment 19

[Robert Mader [:rmader]]

Good news! The Xwayland fix made it into 1.20.10 (https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/560/commits) and there were just two security vulnerabilities found that now force a release (and hopefully quick adoption): https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/563

Comment 20

[Darkspirit]

Xwayland/Ubuntu 20.10 should still be affected by this. It seems they backported only the security fixes.
https://packages.ubuntu.com/groovy-updates/xwayland
https://packages.ubuntu.com/groovy-updates/libegl-mesa0
Instead of dectecting the xwayland version, it should be enough to block WEBRENDER_PARTIAL for Mesa 20.2.x on Xwayland.

Comment 21

[Robert Mader [:rmader]]

Ubuntu 20.10 is already EoL.

Comment 22

[Darkspirit]

(In reply to Robert Mader [:rmader] from comment #21)

Ubuntu 20.10 is already EoL.

RIP. Looks fine elsewhere: https://pkgs.org/search/?q=xwayland