Launchpad has imported 33 comments from the remote bug at https://bugzilla.gnome.org/show_bug.cgi?id=767212.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2016-06-03T17:01:10+00:00 Strangiato Xanadu wrote: Created attachment 329082 bug demonstration I see a black border when I resize a xwayland app window, watch the video please. This black border does not appear when I resize native wayland apps window. My video card is 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] RV710 [Radeon HD 4350/4550] I use the open source driver. Reply at: https://bugs.launchpad.net/ubuntu/+source/mutter/+bug/1751593/comments/0 ------------------------------------------------------------------------ On 2016-06-21T07:45:40+00:00 Ofourdan wrote: Yes, I can reproduce as well *sometimes* - The back area is actually the shadows mutter adds to server-side decorations with the X11 backend. - It seems fairly random - Moving the window might make the issue go away. - It seems to affect some apps more than others (FF, TB whereas I cannot reproduce with xterm for example) - It doesn't seem to be HW/driver related Reply at: https://bugs.launchpad.net/ubuntu/+source/mutter/+bug/1751593/comments/1 ------------------------------------------------------------------------ On 2016-06-21T08:09:20+00:00 Ofourdan wrote: (In reply to Olivier Fourdan from comment #1) > - It seems to affect some apps more than others (FF, TB whereas I cannot Actually it seems to affect gtk2 and Qt based apps and I think this could be related to the use of the _NET_WM_SYNC protocol v1 by these toolkits. As a test, if I disable support for _NET_WM_SYNC in mutter, I cannot reproduce the problem anymore (but obviously resizes are a lot less smooth) Reply at: https://bugs.launchpad.net/ubuntu/+source/mutter/+bug/1751593/comments/2 ------------------------------------------------------------------------ On 2016-06-21T14:32:32+00:00 Ofourdan wrote: (In reply to Olivier Fourdan from comment #2) > Actually it seems to affect gtk2 and Qt based apps and I think this could be > related to the use of the _NET_WM_SYNC protocol v1 by these toolkits. Well, not just v1 actually, forcing X11 backend on gtk3-demo and resizing service-side decorated windows can exhibit the problem as well. And I cannot reproduce with _NET_WM_SYNC disabled ("window->disable_sync = TRUE;" in meta_window_x11_update_sync_request_counter() from window-x11.c) Reply at: https://bugs.launchpad.net/ubuntu/+source/mutter/+bug/1751593/comments/3 ------------------------------------------------------------------------ On 2016-09-01T08:50:21+00:00 Jonas Ådahl wrote: *** Bug 770367 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/mutter/+bug/1751593/comments/4 ------------------------------------------------------------------------ On 2016-09-02T07:40:52+00:00 Ht990332 wrote: So on Xorg, forcing sync eliminates the black box flickering but causes it on Xwayland? Could this be a Xayland bug as suggested in bug 77036? Reply at: https://bugs.launchpad.net/ubuntu/+source/mutter/+bug/1751593/comments/5 ------------------------------------------------------------------------ On 2016-09-02T08:16:52+00:00 Ofourdan wrote: It's two different things imho. _NET_WM_SYNC is not to avoid black box flickering of the drop shadows on X11 (as these are outside the client toplevel window), it's to synchronize frames redraw and avoid resizing faster than the client can cope. For reference, see Owen's description of the the extended synchronisation version of _NET_WM_SYNC used by gtk+ and mutter. It could be a Xwayland bug, possibly, but so far I haven't really found hard evidence of that. Besides, on X11/Xwayland with server side decorations, mutter draws the drop shadows underneath the windows. Reply at: https://bugs.launchpad.net/ubuntu/+source/mutter/+bug/1751593/comments/6 ------------------------------------------------------------------------ On 2016-12-14T08:17:18+00:00 Ofourdan wrote: Quick update - I have been looking into this lately to see if we could use Pekka's proposal of adding an _XWAYLAND_ALLOW_COMMITS property to tell Xwayland when to commit the surface: https://lists.x.org/archives/xorg-devel/2016-November/051913.html https://lists.x.org/archives/xorg-devel/2016-December/051947.html and https://patchwork.freedesktop.org/series/16610/ Before so, I tried to understand what would be causing the back border issue in the first place and traced it down to meta_window_actor_update_opaque_region(). And it's not called from the same code path when using an application that uses _NET_WM_SYNC protocol (e.g. gtk-demo from gtk2) and one who doesn't (e.g. plain old xterm). With XSync protocol: meta_window_x11_update_sync_request_counter() meta_compositor_sync_updates_frozen() meta_window_actor_sync_updates_frozen() meta_window_actor_set_updates_frozen() meta_window_actor_thaw() meta_window_actor_handle_updates() check_needs_reshape() meta_window_actor_update_opaque_region(); Without XSync protocol: clutter_clock_dispatch() master_clock_update_stages() _clutter_run_repaint_functions() meta_window_actor_pre_paint() meta_window_actor_handle_updates() check_needs_reshape() meta_window_actor_update_opaque_region(); Reply at: https://bugs.launchpad.net/ubuntu/+source/mutter/+bug/1751593/comments/7 ------------------------------------------------------------------------ On 2016-12-14T09:51:02+00:00 Ofourdan wrote: Created attachment 341942 [PATCH] MetaWindowActor: Update shape in pre-paint When dealing with clients who support the _NET_WM_SYNC protocol, the shape update is done from meta_compositor_sync_updates_frozen(), but tha can leave (on Xwayland primarily) visual traces of the previous hsape as being cleared by a resize, causing ugly black border flickers. Avoid the issue by updating the shape in pre_paint() as with other clients which do not support _NET_WM_SYNC. -- Note: that (simple) patch seems to avoid the issue, without needing additional synchronization mechanism. Reply at: https://bugs.launchpad.net/ubuntu/+source/mutter/+bug/1751593/comments/8 ------------------------------------------------------------------------ On 2016-12-14T09:51:56+00:00 Ofourdan wrote: Created attachment 341943 [PATCH] MetaWindowActor: Remove uneeded test The is_frozen() function tests for freeze_count >0, so no need to test it twice. -- Note: Trivial simplification, while at it... Reply at: https://bugs.launchpad.net/ubuntu/+source/mutter/+bug/1751593/comments/9 ------------------------------------------------------------------------ On 2016-12-14T10:41:00+00:00 Ofourdan wrote: Review of attachment 341942: It breaks synchronization on X11 so it's not suitable in the general case Reply at: https://bugs.launchpad.net/ubuntu/+source/mutter/+bug/1751593/comments/10 ------------------------------------------------------------------------ On 2017-04-15T19:32:41+00:00 Evgenii Frolov wrote: Also experience this on Fedora 25 (Gnome 3.22 on Wayland). i5-2410M with Sandybridge integrated graphics. Is there any way to help? Reply at: https://bugs.launchpad.net/ubuntu/+source/mutter/+bug/1751593/comments/11 ------------------------------------------------------------------------ On 2017-05-30T01:50:13+00:00 Ikari-0 wrote: I'm also experiencing this issue with applications such as Firefox and Qt Creator, but not with i.e Blender and Chromium and most pre-insalled applications. I'm using Fedora 25 with Gnome 3.22.3 on Wayland, running on an Intel i5-2500 with its own integrated graphics. Reply at: https://bugs.launchpad.net/ubuntu/+source/mutter/+bug/1751593/comments/12 ------------------------------------------------------------------------ On 2017-08-15T18:15:32+00:00 Strangiato Xanadu wrote: testing 3.26 beta... this bug is still happening. Reply at: https://bugs.launchpad.net/ubuntu/+source/mutter/+bug/1751593/comments/13 ------------------------------------------------------------------------ On 2018-01-21T16:00:43+00:00 Max Mustermann wrote: @Olivier Testing your patch with mutter 3.26.2, it does not resolve the problem. It makes the black artifacts outside the windows disappear, however the right and the bottom edge of the window flicker badly inside, black and otherwise, I would say that aspect is worse than before. Anyway I noticed snapping / tiling windows got very smooth in 3.26. I can not see black flickering when tiling to window to half, or dragging it to the top and let it maximize. Would it be possible for you to look into that issue again? This is a very visible issue and makes the Wayland experience bad, especially for users who do not know the reasons. Reply at: https://bugs.launchpad.net/ubuntu/+source/mutter/+bug/1751593/comments/14 ------------------------------------------------------------------------ On 2018-02-08T07:06:13+00:00 Michael Thayer wrote: Pointed to this bug by Jonas Ådahl on the GNOME Shell mailing list. We seem to see something similar when starting VirtualBox. In VirtualBox we need for various reasons to know what the usable area of each screen is - that translates as the largest rectangle which fits on that screen without obscuring any panels or similar. We find that out by mapping a maximised window on each screen at start-up and checking its position and dimensions. To prevent disturbance to the user we create the window fully translucent, or if the X server does not support that we use XShape and leave only a single pixel visible. On GNOME Shell Wayland edition (what is the right way to say that?) this unfortunately flashes a black rectangle up on the screen in the area which should be translucent. (If anyone is interested I explained the why of this on the mailing list[1].) I see this on Ubuntu 17.04 and 18.04 Wayland session, and it has been reported on Fedora too. Please let me know if I should test any patch, including previous ones on this bug. [1] https://mail.gnome.org/archives/gnome-shell- list/2018-February/msg00001.html Reply at: https://bugs.launchpad.net/ubuntu/+source/mutter/+bug/1751593/comments/15 ------------------------------------------------------------------------ On 2018-02-08T08:19:32+00:00 Ofourdan wrote: (In reply to Michael Thayer from comment #15) > Pointed to this bug by Jonas Ådahl on the GNOME Shell mailing list. > > We seem to see something similar when starting VirtualBox. In VirtualBox we > need for various reasons to know what the usable area of each screen is - > that translates as the largest rectangle which fits on that screen without > obscuring any panels or similar. We find that out by mapping a maximised > window on each screen at start-up and checking its position and dimensions. > To prevent disturbance to the user we create the window fully translucent, > or if the X server does not support that we use XShape and leave only a > single pixel visible. On GNOME Shell Wayland edition (what is the right way > to say that?) this unfortunately flashes a black rectangle up on the screen > in the area which should be translucent. XShape might be a different issue than this one (I suspect this is related to ARGB here), but maybe you can provide a simple reproducer that does the same thing as Virtualbox? Reply at: https://bugs.launchpad.net/ubuntu/+source/mutter/+bug/1751593/comments/16 ------------------------------------------------------------------------ On 2018-02-08T08:24:18+00:00 Michael Thayer wrote: It probably wasn't helpful of me to mention XShape here at all. It is only used if ARGB is not available, so is probably not relevant here. I will see if our GUI developer has time to write up a simpler reproduction scenario. He is a (cross-platform) Qt developer rather than an X11/Wayland specialist, so is it alright if it uses Qt? Reply at: https://bugs.launchpad.net/ubuntu/+source/mutter/+bug/1751593/comments/17 ------------------------------------------------------------------------ On 2018-02-08T08:30:29+00:00 Ofourdan wrote: (In reply to Michael Thayer from comment #17) > It probably wasn't helpful of me to mention XShape here at all. It is only Yeap, I understand, jus wanted to avoid mixing potentially different issues :) > used if ARGB is not available, so is probably not relevant here. I will see > if our GUI developer has time to write up a simpler reproduction scenario. > He is a (cross-platform) Qt developer rather than an X11/Wayland specialist, > so is it alright if it uses Qt? Of course it's all right :) I was planning to try with gtk/gdk, but which toolkit the client is using is probably irrelevant (unless the issue lies in the toolkit). One thing to consider is that, from what I found, this is affecting x11 clients using the _NET_WM_SYNC protocol (for example, I don't see any of these with, say, xterm), and both gtk+ and Qt use _NET_WM_SYNC. Reply at: https://bugs.launchpad.net/ubuntu/+source/mutter/+bug/1751593/comments/18 ------------------------------------------------------------------------ On 2018-02-08T10:34:18+00:00 Michael Thayer wrote: Created attachment 368140 Test Qt application which demonstrates the problem This is what our GUI developer provided. Hope it is helpful. Build instructions inside the ReadMe.txt. Reply at: https://bugs.launchpad.net/ubuntu/+source/mutter/+bug/1751593/comments/19 ------------------------------------------------------------------------ On 2018-02-08T10:47:56+00:00 Ofourdan wrote: That really doesn't look like the same issue at all, the entire window is opaque and black, as if it wasn't using transparency at all. Reply at: https://bugs.launchpad.net/ubuntu/+source/mutter/+bug/1751593/comments/20 ------------------------------------------------------------------------ On 2018-02-08T10:56:55+00:00 Michael Thayer wrote: Does it look like something I should open a new bug for? Reply at: https://bugs.launchpad.net/ubuntu/+source/mutter/+bug/1751593/comments/21 ------------------------------------------------------------------------ On 2018-02-08T11:27:07+00:00 Ofourdan wrote: Created attachment 368144 ARGB window using cairo ARGB works fine here, see this example using plain X11 and cairo. The Qt example works with weston, so yes, different issue than this one. Reply at: https://bugs.launchpad.net/ubuntu/+source/mutter/+bug/1751593/comments/22 ------------------------------------------------------------------------ On 2018-02-08T11:35:21+00:00 Ofourdan wrote: (FWIW, trying to get xprop of the transparent Qt mapped window (the one shat shows up black), all I get is “WM_NAME(STRING) = "mutter guard window"”) Reply at: https://bugs.launchpad.net/ubuntu/+source/mutter/+bug/1751593/comments/23 ------------------------------------------------------------------------ On 2018-02-14T15:08:20+00:00 Ofourdan wrote: The “black border” effects comes from the frame window resize. The gdk_window_move_resize() in meta_ui_frame_move_resize() is what causes the border to become solid black, before it's repainted by the compositor. With basic X11 clients, the delay between the gdk_window_move_resize() and the shadow being redrawn is so short that it cannot be seen, but when the X11 client is using a sync mechnaism, the update of the content is delayed until the client has finished updating its content, and in this case the black border is seen for a short time. That explains why the black border shows most with clients with using NET_WM_SYNC protocol and server-side decorations. As an experiment, commenting out the gdk_window_move_resize() in meta_ui_frame_move_resize() makes the problem disappear entirely: https://gitlab.gnome.org/GNOME/mutter/blob/master/src/ui/frames.c#L656 whereas commenting out the call to build_and_scan_frame_mask() in meta_window_actor_update_shape_region() makes the black border visible continuously: https://gitlab.gnome.org/GNOME/mutter/blob/master/src/compositor/meta- window-actor.c#L1699 Reply at: https://bugs.launchpad.net/ubuntu/+source/mutter/+bug/1751593/comments/24 ------------------------------------------------------------------------ On 2018-02-15T08:03:46+00:00 Ofourdan wrote: So yes, bug 757104 is a good idea, setting a different bg color on the gdk window frame changes the color seen during resize, so the black seen comes from the gdk_window background color, before it's eventually repainted by the compositor. (and nope, using a alpha channel of 0.0 in the bg color doesn't avoid the issue) Reply at: https://bugs.launchpad.net/ubuntu/+source/mutter/+bug/1751593/comments/25 ------------------------------------------------------------------------ On 2018-02-15T10:01:29+00:00 Ofourdan wrote: Created attachment 368368 Debug patch to exhibit the issue This patch does: - Set the gdk_window frame gb_color to yellow - Set the metawindow actor color to red - Removes the repaint to black in meta_frames_draw() The idea is to show the yellow/red blinking. To reproduce 1. Build mutter with this patch 2. Run mutter nested: $ jhbuild run mutter --wayland --nested 3. Run gtk3-demo “Application Class” with x11 backend under Wayland: $ DISPLAY=:1 GDK_BACKEND=x11 gtk3-demo --run application_demo 4. Resize the “Application Class” window (that one uses server-side decorations, so decorated by mutter) Now what does this show: 1. The initial color (yellow with this patch) comes from the gdk_window. 2. meta_frames_draw() clears the window to black, that doesn't help! 3. Using an alpha of 0.0 for the GDK window background makes the color black again, as if the mutter's own gdk_window used for the frame wasn't composited... Reply at: https://bugs.launchpad.net/ubuntu/+source/mutter/+bug/1751593/comments/26 ------------------------------------------------------------------------ On 2018-02-15T12:10:07+00:00 Ofourdan wrote: So I reckon the problem is because in Wayland, we update the surface when a new buffer is received. So what happens is, gdk_window_move_resize() clears the frame background, a new buffer is attached once the Xwindow is resized, MetaSurfaceActorWayland repaints using that buffer with the black frame, while repaint of the shadows still awaits for the sync of the client, thus delaying the repaint of the shadows. In the mean time, the black shadows have been seen. Or something around these lines... Reply at: https://bugs.launchpad.net/ubuntu/+source/mutter/+bug/1751593/comments/27 ------------------------------------------------------------------------ On 2018-02-15T12:10:48+00:00 Ofourdan wrote: I mean, I think this is purely a mutter compositor issue. Reply at: https://bugs.launchpad.net/ubuntu/+source/mutter/+bug/1751593/comments/28 ------------------------------------------------------------------------ On 2018-02-19T16:38:48+00:00 Ofourdan wrote: Created attachment 368569 [PATCH 1/2] window: Add set_frozen method This is actually only meaningful for Xwayland as this translates as _XWAYLAND_ALLOW_COMMITS. Reply at: https://bugs.launchpad.net/ubuntu/+source/mutter/+bug/1751593/comments/29 ------------------------------------------------------------------------ On 2018-02-19T16:39:41+00:00 Ofourdan wrote: Created attachment 368571 [PATCH 2/2] window: Fix sync issue causing back borders Using _xwayland_allow_commits() and meta_window_updates_are_frozen(). Reply at: https://bugs.launchpad.net/ubuntu/+source/mutter/+bug/1751593/comments/30 ------------------------------------------------------------------------ On 2018-02-22T13:04:36+00:00 Ofourdan wrote: Comment on attachment 368571 [PATCH 2/2] window: Fix sync issue causing back borders https://gitlab.gnome.org/GNOME/mutter/merge_requests/32 Reply at: https://bugs.launchpad.net/ubuntu/+source/mutter/+bug/1751593/comments/31 ------------------------------------------------------------------------ On 2018-03-20T19:55:19+00:00 Rstrode wrote: let's track this on gitlab only. latest link is here: https://gitlab.gnome.org/GNOME/mutter/merge_requests/53 Reply at: https://bugs.launchpad.net/ubuntu/+source/mutter/+bug/1751593/comments/34 ** Changed in: gnome-shell-legacy-bugs Status: Unknown => Expired ** Changed in: gnome-shell-legacy-bugs Importance: Unknown => Medium -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-shell in Ubuntu. https://bugs.launchpad.net/bugs/1751593 Title: Weird black border flickers around windows in Wayland sessions Status in GNOME Shell: Expired Status in gnome-shell package in Ubuntu: Confirmed Status in mutter package in Ubuntu: Confirmed Bug description: Whenever I open any new window, a black border around the window appears for a fraction of a second (like a flicker). Although this doesn't happen very frequently, happens around 3-4 times out of 10. This is most noticeable when I right click on Desktop and click on "Open terminal". I can replicate this bug every time when I open terminal this way. Also, when I open terminal by pressing Control+Alt+T, the caption buttons kind of grey out after the flicker and are un-clickable. They look as if the window is not at focus. Workaround is to switch to another window (Alt+Tab) and then switch back to terminal. ProblemType: Bug DistroRelease: Ubuntu 17.10 Package: xorg (not installed) ProcVersionSignature: Ubuntu 4.13.0-36.40-generic 4.13.13 Uname: Linux 4.13.0-36-generic x86_64 ApportVersion: 2.20.7-0ubuntu3.7 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Sun Feb 25 19:58:24 2018 InstallationDate: Installed on 2018-02-13 (11 days ago) InstallationMedia: Ubuntu 16.04.2 LTS "Xenial Xerus" - Release amd64 (20170215.2) SourcePackage: xorg Symptom: display UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/gnome-shell-legacy-bugs/+bug/1751593/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : [email protected] Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
