Bug 81275 - resizging windows is slow, flickery and momentous.
Summary: resizging windows is slow, flickery and momentous.
Status: RESOLVED MOVED
Alias: None
Product: Wayland
Classification: Unclassified
Component: XWayland (show other bugs)
Version: 1.5.0
Hardware: Other All
: medium normal
Assignee: Wayland bug list
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-07-12 20:33 UTC by Andrew Engelbrecht
Modified: 2019-05-10 15:12 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Description Andrew Engelbrecht 2014-07-12 20:33:23 UTC
with weston master (and 1.5.0), as i resize an iceweasel window or an arora window, a 1cm black border around the window flickers as the window size changes.

as one moves the mouse to a new position, the window slowly ramps up speed until it comes to the new position, and then the window border keeps moving past the mouse position. (it may eventually move back, but may require moving the mouse a little bit.)
Comment 1 Andrew Engelbrecht 2014-07-13 03:46:20 UTC
i experimented with xman in weston and saw that it had the same problem as iceweasel, but that the flickering was more sparse. in other words, the area around the window wasn't mostly black. xman's window resizing was also a bit faster than with iceweasel. the movement of the window is still reminiscent of sinusoidal motion.

i clicked "Manual Page" in xman, then used my synaptic two finger scroll over the open window. scrolling was very, very slow. i compared this with xman in X11, and noticed that xman in X11 is highly responsive to scrolling. weston master was being used in windowed mode.
Comment 2 Andrew Engelbrecht 2014-07-13 06:05:16 UTC
this appears to be a debian sid bug. i compiled xwayland from source using master and 1.15.99.904 (the version in sid), but did not see this problem.
Comment 3 Andrew Engelbrecht 2014-07-13 06:21:13 UTC
debian bug link, for the curious: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=754651
Comment 4 Pekka Paalanen 2014-07-23 12:29:04 UTC
(In reply to comment #2)
> this appears to be a debian sid bug. i compiled xwayland from source using
> master and 1.15.99.904 (the version in sid), but did not see this problem.

Seeing this and the initial comment in bug #81281 it seems like the issue has been solved. Is this true? If this issue does not exist anymore with xorg-server (xwayland 1.16) and weston 1.5.0 or master, could you mark this bug as fixed?
Comment 5 Andrew Engelbrecht 2014-07-25 18:52:34 UTC
this doesn't appear to be an issue with upstream. it's likely an issue with debian's build system or patch set.

however, bug #81281 is/was still an upstream issue the last time i did a git pull (about several days ago.) bug #81281 creates a far more subtle effect than this.
Comment 6 Andrew Engelbrecht 2014-07-25 18:53:24 UTC
bug is downstream in debian.
Comment 7 Ruud van Asseldonk 2016-11-05 11:29:40 UTC
After Arch Linux upgraded to Gnome 3.22, which runs on Wayland by default, I started experiencing this exact same issue (windows are slow to resize, sometimes a flickering black border appears around windows during resize).

I arrived here via the Debian bug report, but I cannot seem to find what the problem was in the end. Any suggestions on where to look?
Comment 8 Andrew Engelbrecht 2016-11-07 04:15:45 UTC
(In reply to Ruud van Asseldonk from comment #7)
> After Arch Linux upgraded to Gnome 3.22, which runs on Wayland by default, I
> started experiencing this exact same issue (windows are slow to resize,
> sometimes a flickering black border appears around windows during resize).

What hardware do you have? What is the output of:

$ glxinfo | grep -i -e render -e version -e dri
Comment 9 Olivier Fourdan 2016-11-07 08:27:01 UTC
The flickering black border is a known issue with gnome-shell:

  https://bugzilla.gnome.org/show_bug.cgi?id=767212

I suspect this is a frame synchronisation issue between the application and Xwayland.

There are actually two different variations of the sync protocol, using sync counters, one being specified as the extended window manager hints (EWMH) here:

  https://specifications.freedesktop.org/wm-spec/wm-spec-latest.html#idm140200472538288

But mutter/gnome-shell goes further and uses an extended variant of this protocol referred as the "extended synchronization" by Owen here:

  http://fishsoup.net/misc/wm-spec-synchronization.html

gnome-shell/mutter is an X11 window manager/compositing manager and a Wayland compositor as well, when running Xwayland applications that implement either the basic or extended XSync protol as defined by Owen in the link above, the synchronisation is based on the application content which may not match the WM windows content (which are [a] separate window[s]) from the window manager).

So the issue, I reckon, occurs with SSD (server side decorations), as opposed to CSD (client side decorations) applications that implement the Xsync protocol (that pretty much include most of gtk2 apps and some gtk3 apps, those using SSD and not CSD).

This is pretty easy to test, can you reproduce the issue with, say, xterm? (or any basic X11 which does not implement Xsync).

One last note, I am surprised you mentioned the issue occuring with weston because, afaik, weston does not implement the XSync part of the EWMH specs, and I could never reprodcue the issue with weston, so *maybe* what you saw with weston was some other problem more specific to weston.
Comment 10 Adam Jackson 2019-05-10 15:12:32 UTC
(In reply to Olivier Fourdan from comment #9)
> The flickering black border is a known issue with gnome-shell:
> 
>   https://bugzilla.gnome.org/show_bug.cgi?id=767212

This bug is now in gnome's gitlab:

https://gitlab.gnome.org/GNOME/mutter/merge_requests/53


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.