Bug 106841 - XWayland 1.20.0 breaks Chrome/Chromium rendering
Summary: XWayland 1.20.0 breaks Chrome/Chromium rendering
Status: RESOLVED FIXED
Alias: None
Product: Wayland
Classification: Unclassified
Component: XWayland (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Wayland bug list
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-06-06 14:00 UTC by Tony Houghton
Modified: 2018-11-10 16:27 UTC (History)
5 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tony Houghton 2018-06-06 14:00:03 UTC
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.
Comment 1 Olivier Fourdan 2018-06-06 14:12:09 UTC
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?
Comment 2 Olivier Fourdan 2018-06-06 14:17:18 UTC
Oops, sorry, I missed that bit in the first sentence of comment 0, it's GNOME so the compositor is mutter/gnome-shell.
Comment 3 Tony Houghton 2018-06-06 14:35:50 UTC
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.
Comment 4 Olivier Fourdan 2018-06-06 15:33:50 UTC
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”)
Comment 5 Roman Gilg 2018-06-06 16:06:21 UTC
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.
Comment 6 Olivier Fourdan 2018-06-06 16:12:30 UTC
(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.
Comment 7 Roman Gilg 2018-06-06 20:45:21 UTC
(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.
Comment 8 Michel Dänzer 2018-06-07 08:09:09 UTC
(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.
Comment 9 Michel Dänzer 2018-06-07 16:29:47 UTC
https://patchwork.freedesktop.org/patch/228153/ fixes this for me.
Comment 10 Olivier Fourdan 2018-06-08 10:09:53 UTC
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.
Comment 11 Olivier Fourdan 2018-06-08 10:12:11 UTC
actually, triggering the issue is fairly random, and can be achieved simply by pressing “F11” to switch to fullscreen.
Comment 12 Olivier Fourdan 2018-06-08 13:44:01 UTC
FWIW, this patch https://patchwork.freedesktop.org/series/44489/ fixes the issue for me.
Comment 13 Michel Dänzer 2018-06-11 16:37:07 UTC
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
Comment 14 vladimir 2018-08-29 14:02:28 UTC
Hello.
This bug still reproduced with xorg-server 1.20.1
OS: Arch Linux
Chromium: 68.0.3440.106
Comment 15 Olivier Fourdan 2018-08-30 11:30:35 UTC
(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?
Comment 16 vladimir 2018-08-30 14:50:05 UTC
>> 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.
Comment 17 Olivier Fourdan 2018-08-30 15:04:52 UTC
(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).
Comment 18 vladimir 2018-08-30 17:27:01 UTC
>> 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
Comment 19 Olivier Fourdan 2018-08-31 07:07:12 UTC
(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)
Comment 20 vladimir 2018-08-31 07:20:26 UTC
>> `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.
Comment 21 Michel Dänzer 2018-08-31 07:50:50 UTC
(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.