I am using Gnome 3.16 on Fedora 22. Steps to reproduce: 1. start any gtk3-based application which has a main menu (like evolution, gnome-terminal) 2. open the menu 3. move mouse over the menu (right <-> left, not up <-> down). Expected behavior: Mouse pointer should move fast and without any lags. What happens: Mouse slows down. Additional notes: I am not sure whether this is a bug in wayland or gtk3. I don't think any application should be able to slow down whatever displays the mouse pointer. This cannot be reproduced with gtk2 applications (e.g. firefox or geany) or with gtk3 applications under X. I am experiencing similar lags with gtk applications on other UI items but I am unable to reproduce or describe them.
This delay also affects the context menu (right mouse click) on gtk3 applications under wayland. It does not affect the context menu on gtk2 applications.
This lag can be seen in some more different situations: When gtk3 windows are built. Steps to reproduce: 1. Open nautilus 2. right-click on some folder (you will see the lag while the menu is being displayed as described in Comment #1) 3. select "open in new window" You will see a mouse lag until the new window is finished to display. When you move the mouse cursor over window decorations from one window to the next. 1. Open 2 applications (this bug is present with any combination of gtk2, gtk3 and qt applications) 2. move the mouse cursor from one application to the next You will see a slight mouse lag When gnome-shell notifications are displayed Every time gnome-shell displays a notification this causes a mouse lag too. When a gtk3 window gets focused. 1. open 2 gtk3 windows (e.g. nautilus) beside each other 2. select (focus) one of them 3. select (focus) the other one You will notice a mouse lag. This depends on the application type. It seems like this depends on the number of visible UI items: focusing a nautilus window with many items in the currently opened folder and a sidebar takes much more time than focusing an empty gedit window. This only affects gtk3 windows. In gnome-shell activities overview when switching to the application list 1. in gnome-shell go to activities overview 2. press the symbol with 9 squares to open the application list You will notice a mouse lag. As a side note: I am running gnome-shell with animations disabled so I expect all of these operations to be calculated in no time. I am running Fedora 22 on recent hardware with 2 or more CPU cores > 3GHz, nothing older than 5 years, fast RAM, and a GPU which is able to do this under X without problems. There is a related upstream GNOME Bug #745032 - Mouse Tracking 'Laggy' on Wayland
According to upstream bug report this is a issue with mutter (not gtk+). Citing Jasper St. Pierre: > The current theory is that stuff like creating actors, uploading textures to the GPU, etc. all block the main loop.
I can easily reproduce this with gnome-terminal. If you open a gnome-terminal with XDG_BACKEND=wayland, the lag is several times worse.
I have the same issue. Weston runs fast, Gnome-shell runs slow. It's not only menus but anything changing the mouse cursor, like hovering over window edges or hovering things in Google Chrome (extremely slow). Moving the mouse in a circle over Chrome makes the circle degrade to a spiral. Maybe it's time to rewrite the shell in a proper language? https://bugzilla.gnome.org/show_bug.cgi?id=749783
This issue is still present on F23, but it is less noticeable.
This issue is not limited to menus (as pointed out in comment #5). It seems to affect all kinds of user interfaces. Another way to reproduce: 1. install libreoffice-gtk3 2. start libreoffice-gtk3 with GDK_BACKEND=wayland (this is the default as of writing these lines) 3. open any component of libreoffice, e.g. writer You will see a long lag, the whole UI freezes for several seconds!
On F24 this issue is still present, but barely noticeable. The lag rarely is more than one second, mostly during gnome-shell fading notifications in.
Yeah well, it's important to keep in mind that *any* regression compared to X is completely unacceptable and makes the whole idea of "upgrading" the graphics stack to Wayland a failure. My bug got marked as a duplicate of this, even though it has nothing to do with gtk3. I get terrible performance in gnome shell on Wayland. I cannot think of anything more frustrating and anti-immersive than having the mouse cursor lag and drop movements compared to your physical hand movements. I would say this is an absolute critical bug until it is better than X.
A similar upstream bug causing lags and freezes, but I'm not sure they are just over Gtk+ 3.x applications: https://bugzilla.gnome.org/show_bug.cgi?id=760745
I suspect what you are experiencing here is because the Wayland compositor (mutter/gnome-shell) is in charge of managing everything, including the input devices and moving the pointer, so that when mutter/gnome-shell is busy dealing with /something/ else, the mouse pointer will lag.
I encounter the same mouse lag problem when I move my mouse over the categories of the Applications menu, that I installed using this extension https://extensions.gnome.org/extension/6/applications-menu/
I have found that certain extensions cause this issue. If I disable shell extensions using the tweak tool, the lag disappears. There are at least two extensions that appear to be problematic: [Task Bar](https://github.com/zpydr/gnome-shell-extension-taskbar/issues/166) and [All Windows](https://extensions.gnome.org/extension/704/all-windows/). Disabling these just two extensions fixed the problem for me. It seems the issue might be something to do with extensions that poll open windows. If I disable the "tasks" feature in TaskBar, the problem goes away. Also, the problem grows worse as if I have lots of open windows open.
This message is a reminder that Fedora 25 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 25. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '25'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 25 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
I also observe this with Fedora 26
See also https://bugzilla.redhat.com/show_bug.cgi?id=1518722
Fedora 26, GNOME Shell 3.24.3 I am suffering a mouse lag problem too, especially when I right click within some application (evolution): menus open with a very noticeable delay. It started to happen after I installed chrome-gnome-shell, but it still there after I removed it. Unfortunately I do not have a log of what else dnf installed with chrome-gnome-shell. From tweaks/tools I have all extensions on Off, but mouse still lags.
Also: delay is around 4 seconds within gedit. I noticed that even top bar clock is stuck: meanwhile I wait that the menu pops up, clock does not run.
This message is a reminder that Fedora 26 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '26'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 26 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Still happens sporadically in F27, F28.
*** Bug 1597151 has been marked as a duplicate of this bug. ***
This message is a reminder that Fedora 28 is nearing its end of life. On 2019-May-28 Fedora will stop maintaining and issuing updates for Fedora 28. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '28'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 28 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
This message is a reminder that Fedora 29 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 29 on 2019-11-26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '29'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 29 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 29 changed to end-of-life (EOL) status on 2019-11-26. Fedora 29 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.