Bug 1218402 - [regression] mouse lag over gtk3 applications
[regression] mouse lag over gtk3 applications
Status: NEW
Product: Fedora
Classification: Fedora
Component: mutter (Show other bugs)
28
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Matthias Clasen
Fedora Extras Quality Assurance
https://bugzilla.gnome.org/show_bug.c...
:
: 1597151 (view as bug list)
Depends On:
Blocks: WaylandRelated
  Show dependency treegraph
 
Reported: 2015-05-04 15:31 EDT by Christian Stadelmann
Modified: 2018-07-12 04:22 EDT (History)
20 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
GNOME Bugzilla 745032 None None None Never

  None (edit)
Description Christian Stadelmann 2015-05-04 15:31:31 EDT
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.
Comment 1 Christian Stadelmann 2015-05-04 18:05:36 EDT
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.
Comment 2 Christian Stadelmann 2015-05-05 04:56:40 EDT
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
Comment 3 Christian Stadelmann 2015-05-22 14:06:15 EDT
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.
Comment 4 Julian Stecklina 2015-06-11 14:50:33 EDT
I can easily reproduce this with gnome-terminal. If you open a gnome-terminal with XDG_BACKEND=wayland, the lag is several times worse.
Comment 5 alexhultman 2015-06-22 17:30:28 EDT
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
Comment 6 Christian Stadelmann 2015-11-24 16:08:27 EST
This issue is still present on F23, but it is less noticeable.
Comment 7 Christian Stadelmann 2015-11-25 08:30:23 EST
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!
Comment 8 Christian Stadelmann 2016-09-26 15:10:16 EDT
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.
Comment 9 alexhultman 2016-09-26 15:42:22 EDT
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.
Comment 10 Christian Stadelmann 2016-10-07 05:15:09 EDT
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
Comment 11 Olivier Fourdan 2016-10-10 04:24:08 EDT
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.
Comment 12 Gwendal 2017-05-31 10:45:03 EDT
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/
Comment 13 phelps.sg 2017-10-18 07:23:10 EDT
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.
Comment 14 Fedora End Of Life 2017-11-16 14:14:14 EST
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.
Comment 15 phelps.sg 2017-11-28 09:43:50 EST
I also observe this with Fedora 26
Comment 16 phelps.sg 2017-12-29 05:46:45 EST
See also https://bugzilla.redhat.com/show_bug.cgi?id=1518722
Comment 17 mario 2017-12-29 15:26:33 EST
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.
Comment 18 mario 2017-12-29 16:09:31 EST
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.
Comment 19 Fedora End Of Life 2018-05-03 04:51:07 EDT
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.
Comment 20 Anass Ahmed 2018-05-03 10:37:01 EDT
Still happens sporadically in F27, F28.
Comment 21 Paul Howarth 2018-07-12 04:22:59 EDT
*** Bug 1597151 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.