In current Arch Linux with xorg-server-xwayland 1.20.0-5 Chromium has some rendering issues in GNOME Wayland, but not in GNOME xorg. I reported them as <https://bugs.chromium.org/p/chromium/issues/detail?id=849682> (flickering in full-screen video playback) and <https://bugs.chromium.org/p/chromium/issues/detail?id=849693> (corruption when moving windows). They asked me to test with a downgraded xorg-server-xwayland so I ran a git bisect on it. The result was: # first bad commit: [be087778a0eae3093ffdbba3ff7c9f3863d8e1d4] xwayland: Activate Present flips in rootless mode with Glamor I'm fairly confident that's where the moving window corruption starts, but with that version the video flickering is intermittent. Later versions seemed to make the video flickering much more reproducible. I haven't reproduced the bugs in other applications so far (including Firefox and Epiphany/GNOME Web), but I think that doesn't necessarily mean it's Chrome's fault, and I thought you guys might know more about the implications of what was changed in xwayland.
Soddy, I see no flickering in fullscreen video playback with google chrome here... - Which Wayland compositor do you use? - Are you sure it's not tearing, rather than flickering? - When you say moving the window, is that across multiple monitors?
Oops, sorry, I missed that bit in the first sentence of comment 0, it's GNOME so the compositor is mutter/gnome-shell.
It's definitely not tearing, I described it in more detail in <https://bugs.chromium.org/p/chromium/issues/detail?id=849682>. This is a laptop, using just the built-in display, not multiple monitors. I captured a video of the corruption and attached it to the Chrome bug: <https://bugs.chromium.org/p/chromium/issues/detail?id=849693>. I could try capturing the video problem too, but I think the simultaneous decoding and encoding would overload the CPU and affect the result. I probably should have mentioned the GPU, it's Intel Skylake HD 520. It's hidpi, possibly that makes a difference, but my gut feeling is this isn't a hidpi issue.
For the record, to reproduce, one needs to: - Use Chrome's own window decorations (i.e. *not* “system itle bar and borders”) - Enable hardware acceleration (Settings → Advanced → System → “Use hardware acceleration when available”)
I can't reproduce the problems in KWin's Wayland session (with Chrome's own window decoration and enabled HW acceleration). Could it be Mutter not syncing the position of the Wayland surface timely enough to its XWM part? This wouldn't even touch the fullscreen issue though.
(In reply to Roman Gilg from comment #5) > I can't reproduce the problems in KWin's Wayland session (with Chrome's own > window decoration and enabled HW acceleration). Could be that kwin (and weston) both reparent the client window even in the case of client-side decorations, unlike mutter/gnome-shell.
(In reply to Olivier Fourdan from comment #6) > Could be that kwin (and weston) both reparent the client window even in the > case of client-side decorations, unlike mutter/gnome-shell. You are correct. I just tested it with a debug statement in Xwayland for KWin and Weston. Another application to test against, which is not fullscreen, with no decorations is the Steam client. I'm pretty sure it uses Present all the way. At the moment my Mesa 32bit libs are too old for that though.
(In reply to Roman Gilg from comment #7) > Another application to test against, which is not fullscreen, with no > decorations is the Steam client. Steam doesn't hit xwl_present_flip() for me, neither in gnome-shell nor in Weston.
https://patchwork.freedesktop.org/patch/228153/ fixes this for me.
https://patchwork.freedesktop.org/patch/228153/ fixes the issue with moving the window, but the issue with video playback flickering is still present though. I managed to reproduce by starting a playback in youtube on gooble-chrome and then swithcing to fullscreen while playing. The area at the top left matching the “old” window size looks fine, but the rest flickers.
actually, triggering the issue is fairly random, and can be achieved simply by pressing “F11” to switch to fullscreen.
FWIW, this patch https://patchwork.freedesktop.org/series/44489/ fixes the issue for me.
Thanks for the report, fixed in xserver Git master with the commits below. commit 1993f147d08170f07a72e43f0a0f27687e16967b Author: Olivier Fourdan <ofourdan@redhat.com> Date: Fri Jun 8 16:23:44 2018 +0200 xwayland: use pixmap size on present flip commit 10eec2ccb11701fe29ab246acd6c0bdc2991b775 Author: Michel Dänzer <michel.daenzer@amd.com> Date: Thu Jun 7 17:55:21 2018 +0200 present/wnmd: Preserve window pixmap's screen_x/y on flip
Hello. This bug still reproduced with xorg-server 1.20.1 OS: Arch Linux Chromium: 68.0.3440.106
(In reply to vladimir from comment #14) > Hello. > This bug still reproduced with xorg-server 1.20.1 > OS: Arch Linux > Chromium: 68.0.3440.106 Weird, both commit (comment 13) are in xserver 1.20.1 and I just tried again and it works just fine here, no problem (issue reported in comment 0) using google-chrome own decorations and hardware acceleration enabled (comment 4). Are you sure this is the same issue and not something different?
>> pacman -Q |grep xorg-server xorg-server 1.20.1-1 xorg-server-common 1.20.1-1 xorg-server-xwayland 1.20.1-1 My browser config: "background_mode": { "enabled": false }, "browser": { "enabled_labs_experiments": [ "enable-manual-password-generation@2", "enable-password-generation@2", "enable-tcp-fast-open" ], "last_redirect_origin": "" }, "hardware_acceleration_mode": { "enabled": true }, Im using chromium own decorations too, HW acceleration enabled. Disabling acceleration does not solve this problem. Screenshot with bug: https://ibb.co/gbLMCp Let me know how i can help you to find and reproduce this bug.
(In reply to vladimir from comment #16) [...] > Im using chromium own decorations too, HW acceleration enabled. Disabling > acceleration does not solve this problem. > Screenshot with bug: https://ibb.co/gbLMCp That bug doesn't look like the same issue to me. > Let me know how i can help you to find and reproduce this bug. If the bug shows with system window decorations as well, then it's definitely not the same issue (Present is disabled when toplevel are reparented).
>> If the bug shows with system window decorations as well, then it's definitely not the same issue (Present is disabled when toplevel are reparented). With system decoration bug not shows. I think its same issue because its happened after upgrading from 1.9.6 to 1.20.0 and nothing changed after upgrade to 1.20.1
(In reply to vladimir from comment #18) > With system decoration bug not shows. I think its same issue because its > happened after upgrading from 1.9.6 to 1.20.0 and nothing changed after > upgrade to 1.20.1 There are a lot of changes between 1.19 and 1.20 that could possibly affect rendering, though. Couple of things to try: 1. For peace of mind, what gives `xdpyinfo | grep "release number"` on your affected system? 2. Can you try using Xephyr with glamor accel: a. Run a Xephyr server with glamor, e.g.: $ Xephyr -glamor -screen 1280x1024 :12 b. Run a window manager on that server, e.g. mutter: $ DISPLAY=:12 mutter --x11 b. Close all your chromium windows c. Run chromium on that Xephyr server $ DISPLAY=:12 chromium-browser 3. Can you check if xserver 1.20rc1 and 1.20rc2 are affected (Present support for Xwayland was added in between)
>> `xdpyinfo | grep "release number"` vendor release number: 12001000 With Xephyr bug not shows. I will try to build 1.20rc1 and rc2 on this weekend.
(In reply to vladimir from comment #18) > I think its same issue because its happened after upgrading from 1.9.6 to > 1.20.0 and nothing changed after upgrade to 1.20.1 The bugs this report is about are fixed in 1.20.1. Please file your own report.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.