Mouse pointer randomly pauses/stutters in gnome shell Wayland sessions

When displaying an animation using Mutter on Wayland, the pointer appears to move 'jerkey', and the movements are inaccurate.

Rtcm pointed out to me, in IRC, that this might be because on Wayland, Mutter does the mouse tracking, as opposed to X on X. Displaying an animation can use up quite some power, and because of this, Mutter cannot poll the mouse in time.

Examples of animations where this occurs, is the circle animation when moving the mouse to the screen corner, to go in overview mode, and hovering over an application icon in the overview mode.

While this bug isn't a breaking one, it makes it impossible to have a smooth experience on a regular consumer machine.

This patch to clutter improves it slightly, but its far from enough:
https://bugzilla.gnome.org/show_bug.cgi?id=746328

The problem is, as pointed out, that we do too much on the main thread in the compositor.

I'm basically unable to reproduce this (without the Clutter patch) - while I can *sort* of see a hitch in the mouse cursor if I move the mouse with one hand while hitting super with the other I have to stare really hard. I don't see any such effects from other animations.

Jonas - how are you observing this? Do you have a theory why it is happening? I don't see how an animation, even a very expensive one, could have any significant effect on mouse motion. As long as Mutter is displaying new frames, it should be updating the mouse to the most recent reported position.

The current theory is that stuff like creating actors, uploading textures to the GPU, etc. all block the main loop. I can readily produce it on my computer, so perhaps yours is just super fast?

(In reply to Jasper St. Pierre from comment #3)
> The current theory is that stuff like creating actors, uploading textures to
> the GPU, etc. all block the main loop. I can readily produce it on my
> computer, so perhaps yours is just super fast?

Can you describe step by step what you are doing and what you see? The place I see it *most* is with the app picker, if I:

 A) Click on the app picker grid icon in the overview
 B) Immediately move the mouse cursor away

Then I see the something like:

 Mouse cursor freezes for a fraction of a second
 Mouse cursor moves onces
 Mouse cursor freezes again for a smaller fraction of a second
 Mouse cursor moves with a bit of a stutter for the remainder of the animation

But it's all pretty subtle, and if I did what is natural to me and didn't move the mouse cursor at all after clicking the app picker. That doesn't really correspond to what the original poster is saying where the mouse cursor seems ot have problems in any sort of animation, or what Jonas is saying where it sounds like he is seeing a big problem.

It lags while my system seems to be "loading things" (opening the apps grid makes it move for a frame or two and then pause for a half a second, same with opening folders).

Any mouse events processed during that time seem to be poorly processed. It's probably just a psychological thing since I don't have the feedback to make accurate mouse movements, so while they're being processed fine, it feels like it's difficult to control and that it's not working.

(In reply to Owen Taylor from comment #4)
> (In reply to Jasper St. Pierre from comment #3)
> > The current theory is that stuff like creating actors, uploading textures to
> > the GPU, etc. all block the main loop. I can readily produce it on my
> > computer, so perhaps yours is just super fast?
>
> Can you describe step by step what you are doing and what you see? The place
> I see it *most* is with the app picker, if I:
>
> A) Click on the app picker grid icon in the overview
> B) Immediately move the mouse cursor away
>
> Then I see the something like:
>
> Mouse cursor freezes for a fraction of a second
> Mouse cursor moves onces
> Mouse cursor freezes again for a smaller fraction of a second
> Mouse cursor moves with a bit of a stutter for the remainder of the
> animation
>

How I reproduce it on this machine (i7-2620M, Intel HD 3000)

1. Open app grid - mouse freezes for ~1-2 s the first time, then "regular" stuttering similar as described below
2. Move the cursor back and forth below the lowest row of icons - completely smooth movement
3. Move the cursor back and forth over the lowest row of icons (hovering them) - lags and stutters *very* visibly

Without the linked clutter patch, step 3 will result in the cursor ending up moving significantly slower (70% of the distance for the same physical movement), as events gets dropped.

Thinking of that patch again, we still might need it in order to not drop events, as libinput might push events faster than we read them even without frame drops in mutter/gnome-shell. If we happen to end up with two pointer motion events in the queue when dispatching libinput all but the last will end up effectively lost. Its just extra visible when there is tasks taking up extra much of the main thread time.

(In reply to Jonas Ådahl from comment #6)
> (In reply to Owen Taylor from comment #4)
> > (In reply to Jasper St. Pierre from comment #3)
> > > The current theory is that stuff like creating actors, uploading textures to
> > > the GPU, etc. all block the main loop. I can readily produce it on my
> > > computer, so perhaps yours is just super fast?
> >
> > Can you describe step by step what you are doing and what you see? The place
> > I see it *most* is with the app picker, if I:
> >
> > A) Click on the app picker grid icon in the overview
> > B) Immediately move the mouse cursor away
> >
> > Then I see the something like:
> >
> > Mouse cursor freezes for a fraction of a second
> > Mouse cursor moves onces
> > Mouse cursor freezes again for a smaller fraction of a second
> > Mouse cursor moves with a bit of a stutter for the remainder of the
> > animation
> >
>
> How I reproduce it on this machine (i7-2620M, Intel HD 3000)
>
> 1. Open app grid - mouse freezes for ~1-2 s the first time, then "regular"
> stuttering similar as described below
> 2. Move the cursor back and forth below the lowest row of icons -
> completely smooth movement
> 3. Move the cursor back and forth over the lowest row of icons (hovering
> them) - lags and stutters *very* visibly
>
> Without the linked clutter patch, step 3 will result in the cursor ending up
> moving significantly slower (70% of the distance for the same physical
> movement), as events gets dropped.
>
> Thinking of that patch again, we still might need it in order to not drop
> events, as libinput might push events faster than we read them even without
> frame drops in mutter/gnome-shell. If we happen to end up with two pointer
> motion events in the queue when dispatching libinput all but the last will
> end up effectively lost. Its just extra visible when there is tasks taking
> up extra much of the main thread time.

I c

(In reply to Jonas Ådahl from comment #6)
> (In reply to Owen Taylor from comment #4)
> > (In reply to Jasper St. Pierre from comment #3)
> > > The current theory is that stuff like creating actors, uploading textures to
> > > the GPU, etc. all block the main loop. I can readily produce it on my
> > > computer, so perhaps yours is just super fast?
> >
> > Can you describe step by step what you are doing and what you see? The place
> > I see it *most* is with the app picker, if I:
> >
> > A) Click on the app picker grid icon in the overview
> > B) Immediately move the mouse cursor away
> >
> > Then I see the something like:
> >
> > Mouse cursor freezes for a fraction of a second
> > Mouse cursor moves onces
> > Mouse cursor freezes again for a smaller fraction of a second
> > Mouse cursor moves with a bit of a stutter for the remainder of the
> > animation
> >
>
> How I reproduce it on this machine (i7-2620M, Intel HD 3000)

I'm testing with an i5-4200. So considerably faster Haswell graphics, but not much faster overall. It's possible that the differences actually have to do with different input devices and different reporting frequencies or other behaviors - though I don't reproduce anything dramatic either with my laptop's internal touchpad, or switching to a mouse.

> 1. Open app grid - mouse freezes for ~1-2 s the first time, then "regular"
> stuttering similar as described below

1-2s is a lot! - could we be doing some IO in the main thread?

> 2. Move the cursor back and forth below the lowest row of icons -
> completely smooth movement
> 3. Move the cursor back and forth over the lowest row of icons (hovering
> them) - lags and stutters *very* visibly

Do you mean anything different by "lag" and "stutter", or in both cases, do you just mean that the mouse pointer seems to just update rarely.

This is sort of shocking - the amount of drawing and computation being done here should be quite minimal - I have a hard time imaging that we can't do it at 60fps. If I ssh in and take a look at CPU usage when mousing over a row of icons, it's about 33% for gnome-shell. This is definitely way too high - but still not close to what would cause frame drops on its own.

 * What is the CPU usage on your system?
 * What portions of the screen are being redrawn?

> Without the linked clutter patch, step 3 will result in the cursor ending up
> moving significantly slower (70% of the distance for the same physical
> movement), as events gets dropped.

OK - I think the patch is correct - I reviewed it. But it looks like the effect it will cause is not lagging or stuttering, but instead a feeling of molasses. And of course, if there's a difference between moving over empty space and highlighting icons, that means we're dropping frames, which doesn't make sense to me.

(As far as I remember the code, Clutter will fall back to a timer to batch and compress events to 60fps if there is no drawing going on, but never flushes the queue more than 60 times a second.)

> Thinking of that patch again, we still might need it in order to not drop
> events, as libinput might push events faster than we read them even without
> frame drops in mutter/gnom...

I too experience this bug, and it makes GNOME on Wayland really hard to navigate with the mouse on my poor AMD Sempron (1 core, 2.2 GHz).

If I was to measure the cursor in frames per second, I would say that normally and under X I have 60 FPS. But as soon as something starts loading under Wayland (be it icons or menus or whatever), it drops to 0-2 FPS, sometimes even less than that. E.g. if I open the calendar popover, and just move the mouse to the right corner to open the system menu, the mouse stutters as soon as it enters the hover area until the menu get's loaded. While loading the GNOME Shell I am unable to move the cursor at all, although I can move it without the problems with no lag under X, even before the noise background is drawn.

I could live with this, but the sad part is that the keyboard is affected, too. If I search in the Activities overlay for let's say "nautilus" it's not unusual that I get "nauuuuutilus" or "naaaautilus" instead, which is really bad, because if start deleting the characters with backspaces, it lags too, so I end up with the whole word deleted.

Do you use any extensions?

Yes, but nothing that drastically changes the behaviour. Appkeys, Drop down terminal, Media player indicator, Removable drive menu, Top panel workspace scroll, Window demands attention shortcut.

Btw, this bug also occurs in GDM.

Can you try disabling all of your extensions and see if that helps things?

If not, it would be wise to ssh in from another machine and try running `perf top` or `gdb` to get a backtrace where it's getting stuck. If you need help doing that, I can assist you.

I think all the developers here have machines that it runs fine on.

I just tried on my spare clean account I use for testing bugs, and no difference. There was less lag because of the lighter system load (no extensions, no apps running in the background - I always have at least 6 things running in the tray), but still. As I said it also occurs in GDM, even without anyone logged in, so it can't be due extensions.

I don't have another linux computer, but I suppose I could borrow my brother's laptop, but I think I'll need assistance. I only ever used SSH with git.

Alright. If you're on IRC, feel free to ping me there for more real-time help. I'm "Jasper" on both Freenode and GNOME IRC.

I can reproduce this bug even with animations disabled in both gtk and gnome-shell. This mouse lag can also be reproduced just on focus changes as described in https://bugzilla.redhat.com/show_bug.cgi?id=1218402

This lag has been present as far as I remember using GNOME 3 on my laptop. In fact, the move to Wayland exposes it clearly because it makes the mouse cursor freeze. I wrote a shell extension to expose the lag https://extensions.gnome.org/extension/929/buttercheck/ (not yet updated for 3.16) and it happens even on X11.

Another way to show it:
- Alt + F2, "r" and hit return to have a fresh shell
- Open a video and play it
- Hit Super + A
- The shell will stall for at least one full second. That's on a Sandy Bridge laptop with a SSD... not exactly a weak computer.

My best guess here is that the shell uses Meta.LaterType.BEFORE_REDRAW all over the place: https://github.com/GNOME/gnome-shell/search?utf8=%E2%9C%93&q=BEFORE_REDRAW
This causes Clutter to wait for the completion of these events before starting to draw a frame. But, these events generally take a few msc to a few seconds to complete, effectively stalling the entire shell.

After writing this comment I'm gonna measure these stalls and post them here.

Created attachment 303051
Shell js files modified to show BEFORE_REDRAW use

Here's a log when doing the above steps and then pressing Super again to restore the window: http://pastebin.com/fM7DB9fs

ui/main.js:578 later stalled for 634.7280000001192 ms
ui/iconGrid.js:778 later stalled for 370.15100000053644 ms

To test by yourself, extract the attached file in /var/tmp and run:
GNOME_SHELL_JS=/var/tmp/shell gnome-shell replace

Huh, forgot to mention it's for gnome-shell 3.16.1 only. And the correct command is:
GNOME_SHELL_JS=/var/tmp/shell gnome-shell --replace

I also experience this issue on a Thinkpad W540, with an i7-4900MQ and running Fedora 22 (with mesa from git).

I agree with Clement that this has been a bug for a long time on Gnome 3 - various shell actions can stall the entire compositor. The Wayland implementation just makes it a lot worse, because the mouse cursor is included in the repaint loop, but it is a problem even on X.

Things that drop me to 30fps or less on gnome-shell Wayland:
- Maximized GTK2 app (using xwayland)
- Activities icon chooser (15fps or worse)
- Opening gnome-control-center via the user menu (0.2s pause, it was several seconds on gnome 3.14)

Opinions:
- JS probably shouldn't be allowed to block the compositor, ever, because of the possibility of GC pauses.
- Graphically heavy things like the activities menu should probably be a compositor client, rather than happen directly in the compositor.

FWIW I have none of these problems in Weston.

I can confirm comment #16 now, this bug is also present in gnome on X but I didn't notice until now.

Under certain conditions this issue can completely block all GUI to the user: I just ran into a situation where I debugged an application which didn't ever return from finishing to paint/draw menus. Gnome-shell completely freeze, I could not move the mouse cursor or use my keyboard (except for switching to ttys).

You can easily reproduce this by attaching a debugger to any application and setting a breakpoint where it will be called e.g. when the user opens a menu.

So this supports Jasper St. Pierres assumption that this is blocking the mutter main thread.

In the Xorg case, that's because the application took an input grab when it opened, not because mutter's main loop is blocked Can you reproduce the same thing with Wayland?

I don't have the exact same case to reproduce this so I made a small 'test':

I tried these steps to reproduce it under wayland:
1. run any gtk3 application from gdb, e.g. evolution
2. set a breakpoint on gtk_menu_item_deselect
3. use the application menu.

It will freeze your gnome-shell completely. Under both wayland and X the mouse cursor still can be moved and is drawn correctly.
So it is still a bug but I don't know whether it is related or the same.

Christian, I think you should file another issue for this bug. Thanks.

Ok, I filed another issue here: https://bugzilla.gnome.org/show_bug.cgi?id=750092

I think https://bugzilla.gnome.org/show_bug.cgi?id=749783 is a duplicate of this one too.

Mutter 3.16.2 is a huge improvement over prior versions. However, it's still not as good as X.

Ironically, since I updated to 3.28 today, I have experienced a new issue very similar to the one I initially reported in the OP.

It causes the mouse to freeze regularly, and button presses to sometimes not be detected, and at other times be interpreted as very long button presses.

This issue does not make the desktop unusable as the original issue did, and it seems to be only partially related:

https://www.phoronix.com/scan.php?page=news_item&px=GNOME-Performance-Fix-Clutter

(In reply to rk from comment #112)
> And as I understand it, the reasons behind the mouse lag are well understood
> - they're due to the fact that
>
> > Stalls on the main thread stalls compositor frame redraws
>
> and this has been directly addressed in the GNOME Shell 4 proposal
> https://wiki.gnome.org/Initiatives/Wayland/GnomeShell/GnomeShell4 and people
> have talked bout it here in the previous comments.

Exactly. This is why the easiest 'fix' here is to just go back to using Xorg which is what I am doing. I like the idea of Wayland but it can't be the default for GNOME until we can get past this issue, and there is no easy fix, which is why nothing has really been done.

(In reply to Jeroen Bollen from comment #110)
> ...and similarly moving the mouse
> would cause massive frame drops in applications. Just as much as starting a
> hover effect by moving the mouse over a button would freeze the cursor for
> multiple seconds.

I can confirm that this still happens. I experience complete display+input freezes when hover-over tooltips disappear, and when menubar drop-downs or right-click context menus appear or disappear. There are plenty of other simple actions that can cause freezes as well. This doesn't happen right after a clean boot, but can start to occur after an uptime of about an hour.

Interestingly, the behaviour of the freezes is different depending on the app. For instance, tooltop disappearances cause hangs for Firefox and Gvim, but not Evolution and Nautilus, even though all of those apps use GTK3. Also, for some apps, context menus cause a hang only when they disappear, but for other apps, context menus cause a hang when they either appear or disappear.

Created attachment 370171
Screencast of display freezes when gliding the cursor across a set of menubar items

Attached is a screencast of display freezes that can occur in Wayland when menubar items are shown or collapsed. Whenever the cursor stops moving in the video, it's because of a freeze, not because I stopped moving my mouse.

This issue happens to me for menubar items in Evolution and Firefox as well. I suppose it affects any app that supports menubars, though I haven't tested any others.

(In reply to solarquiet from comment #109)
> Also, I've been running GNOME for three days straight (put through suspend,
> wake up and so forth) (3 day uptime) and the gnome-shell process has been
> steadily eating up more RAM. It currently is at 410MB but it really should
> be at around 100-200MB and stay there, this of course depends on how many
> extensions you have. I guess to solve the memory issue on Wayland (since
> alt+f2, r doesn't work), you can log out and log back in.

That issue is now being discussed in: https://gitlab.gnome.org/GNOME/gnome-shell/issues/160

Also, regarding the mouse cursor stuttering/lag:

The issue also is visible when running GNOME Shell on Wayland and having the Dash to Panel extension ( https://extensions.gnome.org/extension/1160/dash-to-panel/ ) installed.

When you move the mouse cursor over the panel, the cursor starts to slow down.

Once you move the mouse cursor outside of the panel, the cursor speeds up again, i.e. is no longer laggy.

It only occurs on Wayland, not on X11.

(In reply to nw9165-3201 from comment #117)
> (In reply to solarquiet from comment #109)
> > Also, I've been running GNOME for three days straight (put through suspend,
> > wake up and so forth) (3 day uptime) and the gnome-shell process has been
> > steadily eating up more RAM. It currently is at 410MB but it really should
> > be at around 100-200MB and stay there, this of course depends on how many
> > extensions you have. I guess to solve the memory issue on Wayland (since
> > alt+f2, r doesn't work), you can log out and log back in.
>
> That issue is now being discussed in:
> https://gitlab.gnome.org/GNOME/gnome-shell/issues/160

Pardon, that was the wrong link, here's the correct one: https://gitlab.gnome.org/GNOME/gnome-shell/issues/64

I can confirm that this issue got way worse on GNOME 3.28 making the mouse freeze more often.

The following situations are especially bad:
1. When a notification is shown, user input freezes for ~2 seconds
2. When switching application focus e.g. by invoking a URL from a feed reader, user input freezes for ~3 seconds.

(In reply to Anass Ahmed from comment #111)
> (In reply to Jeroen Bollen from comment #110)
> > When I opened this bug in 2015, the desktop was unusable on Wayland. It
> > wasn't general performance issues or low frame rates, but GNOME being unable
> > to move the mouse accurately due to performance issues. Animations playing
> > would completely grind the mouse to a halt, and similarly moving the mouse
> > would cause massive frame drops in applications. Just as much as starting a
> > hover effect by moving the mouse over a button would freeze the cursor for
> > multiple seconds.
> >
> > Most comments appear to be from people who are dissatisfied with the overall
> > performance of GNOME, or appear to experience slowdowns over time. Does
> > anyone still experience the original behaviour reported by the bug? I
> > believe this issue has been long solved.
>
> I don't think it has been *completely* fixed.
>
> GNOME Shell notifications still freeze the mouse cursor, tooltips inside the
> GNOME Shell (on Dash Icons) still do the same, and GNOME Shell Menus too.
>
> What was fixed is issues with GTK3 (hovering on icons that produce tooltips,
> or merely opening a GTK menu in LibreOffice ... etc) that was also freezing
> the UI and the mouse cursor.

+1, but even the menu issue is still present when using Evolution on GNOME+Wayland.

(In reply to krinkodot22 from comment #115)
> Interestingly, the behaviour of the freezes is different depending on the
> app. For instance, tooltop disappearances cause hangs for Firefox and Gvim,
> but not Evolution and Nautilus, even though all of those apps use GTK3.
> Also, for some apps, context menus cause a hang only when they disappear,
> but for other apps, context menus cause a hang when they either appear or
> disappear.

The freezes when showing menus only happen when using applications with Wayland as Gtk+ backend. Easy to test with GDK_BACKEND=x11 provided to an affected application.

Regarding the freezes during notifications, see:
https://bugzilla.redhat.com/show_bug.cgi?id=1539258#c17
I experience this as well on Fedora 28.

I just installed Fedora 28 and holy shit...

You know that documentary of how Steve Jobs fired a chief for not understanding the importance of fonts?

Fedora 28 is just completely, utterly unusable. 2 seconds in and my mouse freezes and loses input for _seconds_ and the keyboard input freezes up so that "text" becomes "tttttttteeeeeeeeeeexxxxxxxxxxxxxt". Moving my mouse physically does not translate to the correct distance on screen since random input drop out. It is like trying to thread a needle with parkinsson's dicease and third stage cocaine withdrawal at the same time.

This is readily visible throughout the entire desktop - anything and everything will cause complete input drop out all the time. Completely impossible to work with.

(In reply to Jeroen Bollen from comment #110)
> When I opened this bug in 2015, the desktop was unusable on Wayland. It
> wasn't general performance issues or low frame rates, but GNOME being unable
> to move the mouse accurately due to performance issues. Animations playing
> would completely grind the mouse to a halt, and similarly moving the mouse
> would cause massive frame drops in applications. Just as much as starting a
> hover effect by moving the mouse over a button would freeze the cursor for
> multiple seconds.
>
> Most comments appear to be from people who are dissatisfied with the overall
> performance of GNOME, or appear to experience slowdowns over time. Does
> anyone still experience the original behaviour reported by the bug? I
> believe this issue has been long solved.

What you describe still happens to me.

I see this issue on Fedora 28 while working with IntelliJ allot, its very frustrating.

Hello Alex, any update for this issue? or do we have other sources to make it fixed? How about in git? Thanks

Castro B.
https://alternatives.co/

A fix is now up for review here:
https://gitlab.gnome.org/GNOME/mutter/merge_requests/168

Also the Ubuntu bug for this issue is:
https://launchpad.net/bugs/1690719

@Daniel
I'm testing these branches of yours on mutter:
https://i.imgur.com/gCDvaC8.png
and these (also from Marco) on gnome-shell:
https://i.imgur.com/A90c8y6.png

On the desktop (old gaming radeon card/wayland) the problem is almost solved, meaning that at least the cursor is not stopping for half a second when passing over a menubar with popovers opened.
On the intel laptop (z3735f/wayland) mouse still heavily lagging on menubars/shell popovers/most of gtk widgets and freezing for a good second and half when opening overview (the entire environment freeze when opening overview).
Unfortunately the 30/50% decrease in lag I was hoping for wasn't indipendent on platform's power.
Anyway, to not induce you or others to think that simply the system isn't powerful enough to sustain graphics acceleration, I'm again reinstating that on other wms (weston/kwin/compiz) the system is very smooth:
https://www.youtube.com/watch?v=-xSgzaoHO9Q

Great work! Let me know if I can help somehow.

Oscar

EDIT: Ok I was wrong. On certain aspects even on the laptop it got serious improvements. Window dragging now is very responsive. Also it happens less frequently that shell freezes when writing in Overview.

RE-EDIT: I was super wrong. These changes really made some steps forward.

I'm glad you're seeing improvements.

Just a note though; merge request 168 no longer mentions this bug. Although it does improve the situation for this bug, it's not an absolute final fix for this one. So to avoid any further debate about that it doesn't mention this bug any more.

I'm running Gnome 3.30 on Arch Linux.
General performance improved a lot, but cursor lags are still happening randomly and when shell shows a notification.
My laptop: intel i3 3110m, 8 gib of ram.

I'm running Gnome 3.30 on Fedora 29 (beta).

Mouse stutters under Wayland when:
- alt-tabbing
- opening the Activities menu
- switching workspaces
- hovering over menus e.g. in Libreoffice
- etc.

Also, occasionally there is a longer freeze and then keyboard text becomes teeeeeeeext.

None of these issues are present when using GNOME under X.

It's actually not GNOME's but Fedora's fault to advertise Wayland as a usable, production-ready, thus default choice of environment with these issues, without any end-user advantage besides maybe multi-DPI support.

My laptop: Intel i7, 16Gb RAM.

It seems I have the same issue. But it also affects keyboard key press repeating during the micro friezes. The behavior is slightly different in wayland and xorg session. wayland during such friezes causing multiplied key preses like thisssss, but under xorg just hold for about a second with no repeating keys.
The affected system is openSUSE Tumbleeweed since 20181018 build (20181015 seems to be ok, I've tried it one more time later and didn't notice the issue, it was the last OS build with GNOME 3.28, then it was updated to 3.30)
The hardware is ThinkPad T460 with SSD, 16Gb RAM. On T470p laptop (SSD, 32Gb RAM) with the same OS and packages version it's almost impossible to notice the issue, but it seems to be there too, just not so visible.
In general on T460 it seems like working on desktop remotely via network with some lags.

Same issue: mouse lagging while animating, text becomes teeeeeeext
I'm using GNOME 3.30 on Arch Linux Xeon E3-1505M HD P530 16GB and SSD

I'm quite severely affected by this. Opening the app grid freezes the cursor for 1-2s and even switching applications causes a noticeable freeze.

Why is even mouse input processed on the main thread? Can't Mutter spin up another thread that processes mouse inputs, updates the cursor and the asynchronously sends the events to the main thread for other things? Is there ever a reason that one would like to block cursor updates, and is so, can't the main thread tell the input thread to check with it first only in those circumstances?

Some fixes are on the way for improving the smoothness of mouse movements. See:

  https://gitlab.gnome.org/GNOME/mutter/merge_requests/189
  https://gitlab.gnome.org/GNOME/mutter/merge_requests/651
  https://gitlab.gnome.org/GNOME/mutter/merge_requests/602
  https://gitlab.gnome.org/GNOME/mutter/merge_requests/168

Ok Daniel, is really nice all that work you made for improving the smoothness of mouse movements. Thanks for that, but when will be really fixed that problem and the related problems of this? i.e.:

When the shell will be splitted in several threads, like is suggested in (#62): https://bugzilla.gnome.org/show_bug.cgi?id=745032#c62 ?

This also is how is suggested in: https://bugzilla.redhat.com/show_bug.cgi?id=1367666

So, is nice to have all that workaround to improve the shell performance, but non of this is touching the architecture of the shell yet. This type of bugs like a lot more (see the RedHat issue) that we can percived are just because the selected architecture of the shell (wicth just one thread) don't help. It's not a new and this is not the only one thing where have just one thread is pretty noticiable.

I know that was not you who select that shell architecture and also i know how hard is change that right now, but some work-around to a thing like that (like your own), will only ensure to have more work-arounds and not real solutions. This is just my opinion ofcourse.

Those are not workarounds, they are bug fixes.

I do not know of anyone working on introducing threading yet, but the need for it is rapidly shrinking toward zero.

Yes, when more implementations for fix things that people can easy see will exist, will have less possibility to have a more important and general improve for the fundamentals things. The mouse lagging is just a symptom to me and then your fix, is a fix to a symptom, not to the illness (The illness is have just one thread).

There are people who take medicine all their lives for the symtomps of a disease that has a cure. They can feel good some times, but all their life they will remain sick. Here will be the same? I hope not, but you are right, the convergence to have a real cure tends quickly to zero, when more palliative medicine is created, like your own.

Just some words from my own understanding, maybe incorrect:
No matter with or without threading, I think Daniel's work on performance is important.
They are focus on other performance issues that seems won't be fix by simply doing threading, and can also help on mouse lag.
Threading can fix mouse lag, but it does not means those performance issues can also be fixed by threading, they are just being masked by threading.
Sometimes metaphor can be really misleading, let us focus on the content of those MRs instead.

(In reply to Daniel van Vugt from comment #139)
> Those are not workarounds, they are bug fixes.
>
> I do not know of anyone working on introducing threading yet, but the need
> for it is rapidly shrinking toward zero.

Thanks for your work, Daniel! I hope these get merged into the next GNOME version.

Alynx Zhou, read #138 of course that the fix of Daniel are in extremely important in his context and they are good things that all us will want to happens.

At the same time and unfortunately the Daniel fixes can be used as a justifications to other people to not change the shell architecture. Please see the RedHat issue (in #138) and you will see that point of view there. So, if we celebrate the Daniel improve as a solution here, in a thread where is recognized the importance of have more than one thread in the shell, is to me like forget all previously discussions about that. Is not just here the first time that GNOME developers prefer treat the symptoms instead of the disease. Please see: https://bugzilla.gnome.org/show_bug.cgi?id=687362

I think is important mention that I'm one that follow in gitlab the Daniel improvement's. Now is more difficult to follow the improves because the performance tag was removed recently in gitlab (i don't know why).

I hope my point is more easy to see now. I'm talking of an historical bug that is remain unfixed and apparently it will continue in that way forever.

Lester while I think we all agree it would be good to have a multi-threading gnome-shell, I don't think it's going to happen before a major version upgrade (likely when they rebase on GTK 4). I'm happy using it on X11 for now.

Mike, Gtk4 is an amassing improve of the Gtk toolkit, if we compare it to any previously versions. After the introduction of Gtk4, will also be interesting re-thinking the real advantage that right now provide St and Clutter, compared with directly implement the shell with Gtk (Gtk4). Previously to the Gtk4, the option was Clutter as it have 3D acceleration support by default (Gtk3 not) and because it have a reduced set of API which allows to have a lighter shell than with Gtk. The last idea will continues be in that way.

Anyway, in theory at less, the release of Gtk4 will not affect the shell at all. It need to be a conscience decision, if you want a migration from st-clutter technology to the Gtk4 toolkit. But the decision of migrate the shell from st-clutter to Gtk4 has not been taken at this moment, so we can not ensure that this will happens at all and then we can not wait for that decision or have a plan as a dependency of that.

On the other hand, split the Shell-GUI task and the WM things in separately process is a totally independent thing of what toolkit you use and then will be the same job if it's for Clutter or if it's for Gtk. So, i really don't see the point of be waiting for a new version of Gtk if what really is needed is an architecture decision.

Certainly an architecture change at that level involve rethinking a lot of things and previously create a shared API of Mutter to be used from outside (the shell process) and that API is not yet there. So, I think we can conclude that there are not any intention to go in the direction of split the process yet.

That then means to me, that all us that are waiting for a multi-thread shell in this issue, will continues be waiting. But that not means to me that i will change and stop wanting the solution that a lot of us are waiting for years.

I think we all want to run a shell process with a very higher demand of CPU without blocking the compositor in the most critical point, when the WM is drawing/compositing the windows. I know that i can do that with the right architecture, but I can not do that currently with 16 cores and 32 process, so to me, i have the hardware for it, but I'm waiting for the software yet. None of the solution i see will really help to solve that user-case. The current solutions are just in the direction of minimized the impact, something that is also good, but non of this are the solution I'm waiting for. The current solutions are not even close to that.

I think it might be worth closing this bug now. There's no root causing done at all, the bug is 4 years old, and has turned into a forum discussion.

Please file a new bug in gitlab once Daniel's work (mentioned in comment 137) has landed if there are still problems.

I am now finding these help Wayland cursor movement the most:

https://gitlab.gnome.org/GNOME/mutter/merge_requests/719
https://gitlab.gnome.org/GNOME/mutter/merge_requests/189

The first one allows movement to continue smoothly even when under increasing CPU load. The second one tries to reduce that CPU load. They both work separately, but probably best together.