After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 745032 - Mouse Tracking 'Laggy' on Wayland, and mouse movements cause frame drops in other OpenGL applications
Mouse Tracking 'Laggy' on Wayland, and mouse movements cause frame drops in o...
Status: RESOLVED INCOMPLETE
Product: mutter
Classification: Core
Component: wayland
unspecified
Other All
: Normal normal
: ---
Assigned To: mutter-maint
mutter-maint
: 749783 774014 775162 (view as bug list)
Depends on:
Blocks: wayland WaylandRelated
 
 
Reported: 2015-02-23 16:35 UTC by Jeroen Bollen
Modified: 2019-11-05 20:52 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Shell js files modified to show BEFORE_REDRAW use (391.07 KB, application/x-tar)
2015-05-07 21:19 UTC, Clément Guérin
Details
Key stickiness (51.90 KB, video/webm)
2018-02-17 05:43 UTC, krinkodot22
Details
Screencast of display freezes when gliding the cursor across a set of menubar items (171.45 KB, video/webm)
2018-03-27 04:39 UTC, krinkodot22
Details

Description Jeroen Bollen 2015-02-23 16:35:49 UTC
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.
Comment 1 Jonas Ådahl 2015-03-17 03:22:30 UTC
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.
Comment 2 Owen Taylor 2015-03-17 19:26:30 UTC
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.
Comment 3 Jasper St. Pierre (not reading bugmail) 2015-03-17 19:28:27 UTC
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?
Comment 4 Owen Taylor 2015-03-17 20:01:54 UTC
(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.
Comment 5 Jasper St. Pierre (not reading bugmail) 2015-03-17 21:21:37 UTC
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.
Comment 6 Jonas Ådahl 2015-03-18 02:11:08 UTC
(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.
Comment 7 Jeroen Bollen 2015-03-18 06:00:07 UTC
(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
Comment 8 Owen Taylor 2015-03-18 14:20:00 UTC
(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/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 think "main thread time" is pretty much a red herring as far as that goes - clutter can be sitting idle in the main loop - it's not going to run another batch of events until it gets a frame complete event back from the GPU.
Comment 9 Juraj Fiala 2015-05-02 16:12:13 UTC
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.
Comment 10 Jasper St. Pierre (not reading bugmail) 2015-05-02 16:45:18 UTC
Do you use any extensions?
Comment 11 Juraj Fiala 2015-05-02 17:17:11 UTC
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.
Comment 12 Jasper St. Pierre (not reading bugmail) 2015-05-02 17:20:02 UTC
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.
Comment 13 Juraj Fiala 2015-05-02 17:27:35 UTC
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.
Comment 14 Jasper St. Pierre (not reading bugmail) 2015-05-02 17:29:39 UTC
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.
Comment 15 Christian Stadelmann 2015-05-05 08:58:14 UTC
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
Comment 16 Clément Guérin 2015-05-07 19:00:32 UTC
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.
Comment 17 Clément Guérin 2015-05-07 21:19:33 UTC
Created attachment 303051 [details]
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
Comment 18 Clément Guérin 2015-05-07 21:57:05 UTC
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
Comment 19 Thomas Daede 2015-05-10 20:04:51 UTC
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.
Comment 20 Christian Stadelmann 2015-05-22 18:11:16 UTC
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.
Comment 21 Jasper St. Pierre (not reading bugmail) 2015-05-22 18:45:47 UTC
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?
Comment 22 Christian Stadelmann 2015-05-28 12:28:44 UTC
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.
Comment 23 Clément Guérin 2015-05-28 12:44:03 UTC
Christian, I think you should file another issue for this bug. Thanks.
Comment 24 Christian Stadelmann 2015-05-29 10:05:11 UTC
Ok, I filed another issue here: https://bugzilla.gnome.org/show_bug.cgi?id=750092
Comment 25 Christian Stadelmann 2015-06-23 12:31:51 UTC
I think https://bugzilla.gnome.org/show_bug.cgi?id=749783 is a duplicate of this one too.
Comment 26 Alex Hultman 2015-07-03 20:31:52 UTC
Mutter 3.16.2 is a huge improvement over prior versions. However, it's still not as good as X.
Comment 27 Peter Hutterer 2015-10-29 01:33:00 UTC
Note that under X with evdev and synaptics, the mouse cursor rendering is handled in the SIGIO handler, thus interrupting anything else the server currently does. So even if the server is flat out busy, the mouse cursor will update.

Under X with the libinput driver, we currently don't use the SIGIO handlers. So if the server is busy rendering, the cursor stalls (https://bugs.freedesktop.org/show_bug.cgi?id=92720). I suspect all reproducers above would've used the libinput driver to reproduce this under X.
Comment 28 Alex Hultman 2015-10-30 15:46:10 UTC
When Chrome is lagging a lot I get stutterings in mouse movement even on X using libinput, but normally it works without issues. But the Wayland situation is still very much unusable as of 3.18. Just an update on the situation. I personally think mouse movement should be handled with the absolute highest priority possible (interrupts all the way). Movement should never ever be lost.
Comment 29 Kamil Páral 2015-11-11 14:52:57 UTC
I see this with mutter-3.18.1-4.fc23.x86_64, usually when starting a new app. I can reproduce this in a way, if I start slowly and fluently moving the cursor left and right, and start pressing Win+A (so that app drawer is opened and closed). With every drawer animation, the mouse hitches slightly (if you start pressing Win+A really quickly, the mouse pointer gets visibly jerky).
Comment 30 Alex Hultman 2015-11-18 20:17:07 UTC
*** Bug 749783 has been marked as a duplicate of this bug. ***
Comment 31 Thomas Daede 2015-11-23 22:09:38 UTC
(In reply to Peter Hutterer from comment #27)
> Under X with the libinput driver, we currently don't use the SIGIO handlers.
> So if the server is busy rendering, the cursor stalls
> (https://bugs.freedesktop.org/show_bug.cgi?id=92720). I suspect all
> reproducers above would've used the libinput driver to reproduce this under
> X.

On Fedora 23 with Gnome 3.18, I can reproduce all of the above bugs (2s stall while opening app tray, cursor framerate drop with fullscreen HexChat and Thunderbird, other random frame drops) in Wayland.

They do not reproduce in X with libinput. To be specific, the compositor still stalls heavily while opening the app tray, but the mouse cursor can still move while this happens.
Comment 32 Alex Hultman 2015-11-23 22:24:16 UTC
I have libinput in X and I can get the mouse to stall from many things. Opening system settings causes stall, closing system monitor does, Chrome when lagging does, etc. The issue is just not as bad in X as when running Wayland.
Comment 33 Julio Ordonez V 2015-11-25 03:35:45 UTC
Same issue here,mouse pointer lags fedora 23, mutter, gnome shell 3.18.3 on wayland (issue does not happen on x, also tested on weston and there are no issues there) , pointer lags, keyboard inputs too, if I type something in the browser it freezes and then the letter I typed appears several times as if I typed several I would  get severrrral displayed. running on a low spec laptop lenovo chromebook x131e
Comment 34 Oliver Wngr 2015-12-21 22:22:22 UTC
After around 30min of usage, gnome-shell takes up about 30% of CPU. Then, I experience the pointer lagging as well.
Lenovo T440s, i5
Comment 35 Juraj Fiala 2016-03-23 20:06:34 UTC
This is still an issue on 3.20, which is a shame, because wayland makes everything else really fluid.
Comment 36 Emilio Cabrera 2016-06-26 21:24:18 UTC
I have this same issue and this one https://bugzilla.gnome.org/show_bug.cgi?id=757942 on Gnome 3.20.2 on Fedora 24 on a HP 240 G3 with a Celeron N2840 but the problem was caused due to a extension to manage the clipboard, should I fill another bug?
Comment 37 Christian Stadelmann 2016-06-26 21:50:01 UTC
(In reply to Emilio Cabrera from comment #36)
> I have this same issue and this one
> https://bugzilla.gnome.org/show_bug.cgi?id=757942 on Gnome 3.20.2 on Fedora
> 24 on a HP 240 G3 with a Celeron N2840 but the problem was caused due to a
> extension to manage the clipboard, should I fill another bug?

Looks like a bug in this extension so you probably should file it there.
Comment 38 srakitnican 2016-09-04 10:28:29 UTC
For my case, I have a slower 2.5" mechanical drive on which I keep test installs. Mouse cursor appears when GDM starts loading and is freezed in the center until GDM fully loads, same for Gnome. That could be as high as 30 seconds. On SSD on the the other hand, since stuff loads faster, stutter is not apparent so much.

In addition to that I am experiencing random freezes when using gnome recently on F25/26, when I ssh from a remote computer I can't see any unusual disk or CPU load, all seems normal. Not sure what is going on.
Comment 39 Christian Stadelmann 2016-09-05 11:43:28 UTC
I'm seeing this issue sometimes, especially while notifications (e.g. from evolution) are animated to fade in. Also happens during high CPU or I/O load. Looks like another reason to split UI (shell) from compositor into two different processes.
Comment 40 Christian Stadelmann 2016-10-09 13:18:49 UTC
Bug https://bugzilla.gnome.org/show_bug.cgi?id=760745 might have been a trigger or cause for this bug. Try whether this is fixed with mutter 3.22.1.
Comment 41 Juraj Fiala 2016-10-13 19:15:15 UTC
No, no difference. Also a bigger issue than mouse stuttering is keyboard stuttering, especially when searching in the shell, which leads to stuff like thiiiiiis.
Comment 42 Clément Guérin 2016-10-14 00:08:08 UTC
As I said in comment #16, it's an much deeper issue that has been around since the 3.0, the only difference is that now the mouse and keyboard wrong along with the compositor.

Some ideas to fix this:
- optimize the window layout code, it looks atrociously slow
- decouple the compositor from I/O access and make everything asynchronous so that it never ever blocks
- as far as I understand the mouse cursor is rendered by the compositor under wayland, is there any way to revert back to a hardware cursor?
Comment 43 Alex Hultman 2016-10-14 00:15:02 UTC
Wayland is awesome in itself (Weston has really nice performance, love the graphical perfection of apps), but the fact that Mutter/GNOME Shell is built as some kind of JavaScript/C blob makes no sense when you now are promoting the compositor to act as the server also. I just feel like the GNOME Shell performance simply doesn't cut it. Even if Xorg is old as shit and slow, it still brings far better user experience than the current JavaScript-based Wayland. I love Red Hat but it needs to be an improvement over X, it cannot be freezing and losing input like this. Toss out JavaScript and build it with a real language.
Comment 44 Clément Guérin 2016-10-14 00:18:05 UTC
JS is not the issue in itself, the fact that it is able to stall the C code is the real problem.
Comment 45 Alex Hultman 2016-10-14 00:28:52 UTC
Well JavaScript is always something to consider when perf is an issue. If you invite JS to your home, it will rob you of everything you own and leave you with nothing but AIDS. I can get, what feels to be, 300fps in weston while the shell feels like 30 fps. It is such an enormous difference in feel.
Comment 46 Alex Hultman 2016-10-14 00:39:07 UTC
Sorry for spamming or acting like a troll but this is a real issue: how do you guarantee the JS code won't trigger a GC process in the middle of something critical? When the GC kicks in, you will freeze the entire main thread.
Comment 47 Clément Guérin 2016-10-14 00:48:27 UTC
Yes, and that's exactly why JS code not blocking the compositor is the solution.
Comment 48 Alex Hultman 2016-10-14 00:55:26 UTC
So instead of removing the unreliable piece of code that can decide to freeze at any time, you are going to wrap it into some kind of threading kindergarten?

This sounds like insanity to me.
Comment 49 Clément Guérin 2016-10-14 01:01:50 UTC
Well the gnome-shell codebase is 6 years old now. It would be a huge task to rewrite it entirely and it doesn't matter anyway, because this is not the real issue. Plus it would break user extensions.
Comment 50 Kamil Páral 2016-10-14 09:42:19 UTC
Please discuss this elsewhere, this is not a chatbox. Only post a new comment when you have something valuable to add. Thank you.
Comment 51 Kadir 2016-12-01 18:42:01 UTC
Hi, 

I too experience this bug under Fedora 25 (while using Wayland). I have opened a bugreport downstream (https://bugzilla.redhat.com/show_bug.cgi?id=1398423).

This bug makes using Gnome (3.22.2) + Wayland unusable for me. On my Sandy Bridge laptop (Dell Latitude e6320 with HD3000) the stutter is awful and it makes using the mouse unpredictable.
Comment 52 jeremy9856 2016-12-11 07:03:57 UTC
*** Bug 774014 has been marked as a duplicate of this bug. ***
Comment 53 Daniel Colascione 2016-12-23 23:10:00 UTC
If you want to fix this problem correctly, then in addition to decoupling the JS engine from the compositor thread, you'll also want to call mlockall(2) in the compositor process (to prevent page faults and swapping under system memory pressure) and run with SCHED_FIFO (or other real-time scheduling class) to make sure that CPU-intensive workloads don't starve the compositor process. You need to make the entire process SCHED_FIFO or you'll get priority inversions with process-wide locks (like the heap lock), so you're best bet is giving the compositor its own process and putting the shell elsewhere.

Everything else is a half-measure.  If you want the GUI to be responsive under load, you need to insulate the GUI _from_ load, and the previous paragraph describes how to do that.
Comment 54 Nick Tenney 2017-02-06 03:28:38 UTC
I did a bunch of searching to finthe cause of another similar issue (Running Diablo 3 in wine in the wayland gnome session).  This prompted me to try alternate situations, and I found that weston's configuration was oodles smoother than even the gnome xorg session.  This causes severe issues in that game and others.  I really like using gnome, but this is becoming a bit of a deal breaker.  My desktop is an i7-920, so it really shouldn't lack in compute power considering what it's doing, so it's sad that a cursor can't keep up.
Comment 55 Jean-François Fortin Tam 2017-04-10 23:28:31 UTC
I just discovered something that was not readily apparent to me before as a symptom of this bug: it is not just the mouse feeling laggy, but mouse movements actually *cause* frame drops in other applications.

For example, if I run Geeks3D's GPU test "furmark" (available from http://www.phoronix-test-suite.com/benchmark-files/GpuTest_Linux_x64_0.7.0.zip ) like this:

DISPLAY=:0 ./GpuTest /test=fur /fullscreen

...I get okay-ish performance if not touching anything, but whenever I move the mouse cursor over it, frame drops significantly. Demonstration of the issue: https://youtu.be/DUV0vRGFIBU

This was tested on a clean startup with no other applications running. This might be a useful test case for anyone coding towards a solution here.
Comment 56 Douglas 2017-05-01 13:57:45 UTC
In addition, the mouse responds slower during games, to the point where you can't turn around fast enough to respond to a surprise attack. It's like a 0.7 second lag. CSGO has the worst of it. No settings will make it faster.
Comment 57 Nate Graham 2017-05-01 23:51:36 UTC
*** Bug 775162 has been marked as a duplicate of this bug. ***
Comment 58 Matt McCann 2017-05-02 17:53:26 UTC
I've been trying to get to the bottom of this issue with Gnome for awhile and this bug report was posted in the Fedora Reddit earlier today.  I experience lag of both windows the cursor on Arch and Fedora.  I was just curious how hard it is going to be to address this and if there is any plan going forward to attack it. Thank you.
Comment 59 Alex Hultman 2017-05-02 18:10:09 UTC
I also experience lagging windows. I updated from Fedora 22 to 25 yesterday and two things are obviois: text look crystal sharp, and dragged windows update in about 10-15 fps. As reference point I get 290 fps in a certain Steam game so my system is high end with proper drivers working.
Comment 60 Buck Shockley 2017-05-22 02:57:50 UTC
No lagging cursor, but bad lag when moving windows, especially if, say, a YouTube video is playing.
Comment 61 Jakub Szafrański 2017-05-24 14:09:55 UTC
This issue has been reported almost 2 years and 3 months ago. Are we gonna get a response from the upstream on wheter or not this is going to get fixed?

I have a pretty good laptop, and it's annoying that it lags. Xorg works "good enough" for me, wayland is way faster - and it would be a great replacement, if not for this annoying issue. 

I'm currently running GNOME Shell 3.22.3 on Fedora 25, and I'll be happy to provide as much debug information as you guys require, if that helps getting this bug taken care of.
Comment 62 Jonas Ådahl 2017-05-25 01:22:57 UTC
There are plans to fix this. When it comes to the responsiveness of just the mouse cursor, we'll probably move libinput processing to its own thread (as is done on recent versions of Xorg) where it can directly update the hardware cursor without waiting for main drawing loop. This would probably involve moving the libinput backend from clutter to mutter, and adding mutexes shared by the KMS code and libinput backend. Doing this will not affect latency issues related to clients receiving input events; that'll require much larger changes, such as splitting up the shell UI into a separate process.
Comment 63 Strangiato 2017-05-25 01:37:43 UTC
Thanks for all information Jonas.
I'm waiting a fix to this problem, I see many lags on my laptop running Gnome 3.24.2 under Wayland.
Comment 64 Alex Hultman 2017-05-25 02:22:03 UTC
Nobody has mentioned NVIDIA in this thread so far so I think this is new info:

I have NVIDIA proprietary drivers (381.22) on Fedora 26 (Linux 4.11.1) and I can start a Wayland session. I tested for maybe 5 minutes and during these 5 minutes the mouse was responsive for about 10 seconds total. It froze for many many seconds a time. The only place where the cursor was somewhat responsive was on the wallpaper. Hovering anything other completely froze everything up. If you want to trigger this bug in a very obvious way, use my set-up.
Comment 65 solarquiet 2017-05-29 07:17:21 UTC
Recently, GNOME 3.25 (development branch) has had some performance fixes among others.

Read here: https://www.phoronix.com/scan.php?page=news_item&px=GNOME-Mutter-3.25.2

Fingers crossed that GNOME will finally run smoothly in the upcoming GNOME 3.26!
Comment 66 Olav Vitters 2017-05-29 07:44:24 UTC
(In reply to Jonas Ådahl from comment #62)
> There are plans to fix this. When it comes to the responsiveness of just the
> mouse cursor, we'll probably move libinput processing to its own thread (as
> is done on recent versions of Xorg)

Is this bit planned for 3.26? If so, could we either get a new bug for that or use this bug for that (and open a new one for the remaining bits)?
Comment 67 Jonas Ådahl 2017-05-31 03:37:37 UTC
(In reply to Olav Vitters from comment #66)
> (In reply to Jonas Ådahl from comment #62)
> > There are plans to fix this. When it comes to the responsiveness of just the
> > mouse cursor, we'll probably move libinput processing to its own thread (as
> > is done on recent versions of Xorg)
> 
> Is this bit planned for 3.26? If so, could we either get a new bug for that
> or use this bug for that (and open a new one for the remaining bits)?

I'm not sure anyone has it on their todo for 3.26. Opening separate bugs for those two things sounds like a good idea though.
Comment 68 Lester Carballo 2017-06-21 02:07:23 UTC
(In reply to Jonas Ådahl from comment #62)
> There are plans to fix this. When it comes to the responsiveness of just the
> mouse cursor, we'll probably move libinput processing to its own thread (as
> is done on recent versions of Xorg) where it can directly update the
> hardware cursor without waiting for main drawing loop. This would probably
> involve moving the libinput backend from clutter to mutter, and adding
> mutexes shared by the KMS code and libinput backend. Doing this will not
> affect latency issues related to clients receiving input events; that'll
> require much larger changes, such as splitting up the shell UI into a
> separate process.


"such as splitting up the shell UI into a separate process." For me, this is the solution other things are patches... I have stumbled upon this a lot of times by doing an extension. To reduce the impact, I had to split the task into several parts that would be processed in a chain of idle subprocess. Thats give to mutter a chance to process the pending tasks.
Comment 69 Strangiato 2017-09-25 18:57:14 UTC
Still many cursor lags on Gnome 3.26...
It's not possible a good user experience until this big problem is fixed.
Comment 70 Michael Biebl 2017-09-26 14:55:04 UTC
Sorry for posting a me too, but since Debian switched GNOME to Wayland in 3.26, I see this behaviour as well. Sometimes the mouse cursor freezes completely for multiple seconds, e.g. when compiling stuff or transferring large amounts of data over USB. This is with the intel driver (X220). I don't see this behaviour with the GNOME on Xorg session. I'm happy to run further diagnostics if needed.
Comment 71 Lester Carballo 2017-09-26 22:08:56 UTC
That happening for a long time, just is not really easy to be see on X11, separate all things to have more that one thread will also contribute to solve this old issue: https://bugzilla.gnome.org/show_bug.cgi?id=687362
Comment 72 purfett 2017-10-02 13:24:17 UTC
Can confirm this same problem on a bay trail notebook with integrated intel graphics, either with touchpad and mouse; of course not experiencing it on X11.
version 3.24.0 on ubuntu 17.04
Comment 73 Jan Niklas Hasse (Account disabled) 2017-10-02 19:18:17 UTC
No need for confirmation as this happens on every version and every hardware.
Comment 74 Jakub Szafrański 2017-10-13 10:19:01 UTC
So, is there any planned upcoming release when this will get fixed?
Comment 75 André Klapper 2017-10-13 11:04:04 UTC
No, because without knowing exact reasons for this behavior and without proposed code changes so far it is not possible to say "when this will get fixed".
Comment 76 roidal 2017-10-13 12:35:24 UTC
Should this issue not be handled with higher priority? It makes FPS-games almost unplayable within a wayland-session. But they are already default on some linux-distributions.
Comment 77 Jan Niklas Hasse (Account disabled) 2017-10-13 12:37:05 UTC
> It makes FPS-games almost unplayable within a wayland-session.

Are you sure that isn't because of https://bugzilla.gnome.org/show_bug.cgi?id=788493 ?
Comment 78 roidal 2017-10-13 12:53:23 UTC
(In reply to Jan Niklas Hasse from comment #77)
> > It makes FPS-games almost unplayable within a wayland-session.
> 
> Are you sure that isn't because of
> https://bugzilla.gnome.org/show_bug.cgi?id=788493 ?

I don't think so. The bug is related to gnome-version 3.26 but i have the problem with FPS-games since wayland-session is active (Fedora 22, Gnome 3.22).
Comment 79 roidal 2017-10-13 12:58:47 UTC
(In reply to roidal from comment #78)
> (In reply to Jan Niklas Hasse from comment #77)
> > > It makes FPS-games almost unplayable within a wayland-session.
> > 
> > Are you sure that isn't because of
> > https://bugzilla.gnome.org/show_bug.cgi?id=788493 ?
> 
> I don't think so. The bug is related to gnome-version 3.26 but i have the
> problem with FPS-games since wayland-session is active (Fedora 22, Gnome
> 3.22).

Sorry,
Fedora 25 of course.
Comment 80 tenten8401 2017-10-13 13:30:49 UTC
I really hope they fix this bug as it's the primary reason I'm currently using Plasma right now. Tons of my games just have so much input lag and stuttering they're unplayable when I have a couple windows open, even with high framerates on X11. Doesn't happen on Plasma.
Comment 81 Jan Niklas Hasse (Account disabled) 2017-10-13 13:34:01 UTC
> Tons of my games just have so much input lag and stuttering they're unplayable when
> I have a couple windows open, even with high framerates on X11.

Not sure if I understood you correctly, but that sounds like a different bug (https://bugzilla.gnome.org/show_bug.cgi?id=788493 maybe?) as this one is about Wayland only.
Comment 82 Florian Will 2017-10-19 18:42:06 UTC
I think the general lag / low FPS of some shell animations is not a huge problem. We've lived with that using X for many years. Just very short, hardly noticable UI freezes that we're all accustomed to. No need to throw out Javascript. ;-)

It only becomes very bad when using Wayland, because it reduces the mouse cursor FPS as well and makes the system very difficult to use in my case, as correctly targeting/approaching items on the screen is hard (AMD Phenom II 955 CPU and AMD HD7870 using Mesa drivers). I'm using the Ubuntu 17.10 default session, so not vanilla Gnome, but it should be the same issue (most reproducers described above work for me).

So I hope you're not trying to fix the general UI sluggishness of the Gnome shell first, which is only a slight annoyance and probably a huge work item. A solution that gives priority treatment to mouse cursor updates to always keep mouse cursor FPS at ~60 would probably solve most complaints people have and hopefully doesn't require big design/architecture changes. Until then, I'll use the X session. BTW, the Wayland smoothness (when Gnome shell is not suffering from micro-freezes) is impressive!
Comment 83 Schlomo Shekelstein 2017-10-21 19:59:54 UTC
This is one of those bugs that's not very fun to fix, like JWZ talked about in his "Cascade of Attention-Deficit Teenagers" post. Better just wait for the next rewrite.
Comment 84 André Klapper 2017-10-22 13:28:08 UTC
Please refrain from posting comments that do not help getting a bug closer to getting fixed. There are random other places for that. Thanks.
Comment 85 Eero Tamminen 2017-10-22 17:58:35 UTC
Is Mutter using cursor plane for updating the mouse cursor on screen, or something slow, like using normal 3D pipeline to update it?

Latter would mean that:
* Visible mouse updates are slowed down to application frame update speed when they're mixed with slow application frames in the GPU batch queue (FurMark on integrated GPU is good example of that)
* Much larger memory bandwidth usage overhead, because AFAIK most 3D drivers don't support partial screen updates, so all mouse updates would be fullscreen renders, instead of updates just for the cursor plane onscreen co-ordinates
Comment 86 Thomas G 2017-10-30 02:13:11 UTC
Well, cursor FPS could be a small problem and we could get used to it. Unfortunately, in some extrem cases the lag is so intense that it nearly freezes the mouse which leads to a crash, by turning the computer into a brick.

For example (so, be careful when opening those! depending on your configuration, it could be the last thing you will have done in this session... You've been warned), Chrome Experiment gives a tone of different mouse lag direct experience, with the 3D tag: https://experiments.withgoogle.com/chrome?tag=3D

On my computer in Chrome (with a Radeon HD 4770), this demo leads to a very slow mouse: https://demo.marpi.pl/archan/eutow/ and it's not linked with the amount of 3D to compute, because for example this demo: http://alteredqualia.com/three/examples/webgl_materials_skin.html is super fast and does not lead to mouse freeze.

This one leads to mouse freeze: http://www.zynaps.com/site/experiments/blox.html /!\ /!\ BE CAREFUL /!\ /!\

So, I'm back to X for now, but I hope that it will be corrected
Comment 87 sustmidown 2017-11-15 08:07:49 UTC
I guess this page is highly related to this problem: https://wiki.gnome.org/Initiatives/Wayland/GnomeShell/GnomeShell4

It describes that Gnome Shell 3 was designed to be used with X11 and it depends on the ability of X11 to handle low latency interaction.

Hopefully, the lag issues will be solved in Gnome Shell 4.
Comment 88 Lester Carballo 2017-11-15 09:53:23 UTC
(In reply to sustmidown from comment #87)
> I guess this page is highly related to this problem:
> https://wiki.gnome.org/Initiatives/Wayland/GnomeShell/GnomeShell4
> 
> It describes that Gnome Shell 3 was designed to be used with X11 and it
> depends on the ability of X11 to handle low latency interaction.
> 
> Hopefully, the lag issues will be solved in Gnome Shell 4.

I like the idea of Gnome Shell 4. Very nice to see this soon, also if we lost all code that we have actually. I hope gnome shell 4 will be develop in parallel with Gnome 3, so in that way we can see it when really it will be stable. Gnome Shell 4 it's then to me a desktop for this times, as will exploit the parallel processing and a non complete monolithic architecture making it much more stable and faster, then much more usable. Gnome 3 is not anything of this.
Comment 89 Kadir 2017-11-15 10:15:33 UTC
I really want Option A of the proposal for gnome-shell 4.0 to be implemented, it would really be good for the future of Gnome and GNU+Linux in general
Comment 90 Jonas Ådahl 2017-11-15 10:25:57 UTC
The things written down on that wiki page is so far only ideas / brain storming. This bug is about laggy mouse cursor movements, so please stay on topic. The plan for how to fix that part is mentioned in comment 62.
Comment 91 Lester Carballo 2017-11-15 14:14:15 UTC
(In reply to Jonas Ådahl from comment #90)
> The things written down on that wiki page is so far only ideas / brain
> storming. This bug is about laggy mouse cursor movements, so please stay on
> topic. The plan for how to fix that part is mentioned in comment 62.

To be honest, i don't think you will want to move the GUI outside the compositor (it will be equivalent to a lot of work), but that will resolved all current and also future problems like this. Or this: https://github.com/lestcape/Gnome-Global-AppMenu/issues/67 So, i don't see this bug as laggy mouse cursor movements. I see this as a wrong architecture of the shell. So, how we can help on this if it's a wrong conception of the shell itself, without re-thinking almost how components are interacting as a whole like your own comment also?
Comment 92 André Klapper 2017-11-15 14:40:47 UTC
This ticket is about laggy mouse cursor movements. If you want to discuss meta-level gnome-shell architecture, please use corresponding mailing lists: https://mail.gnome.org/ . Not in this task.
Comment 93 Lester Carballo 2017-11-15 15:32:08 UTC
(In reply to André Klapper from comment #92)
> "Tf you want to discuss meta-level gnome-shell architecture..."

Do you read the comment #62? This is what is proposed there, a redefinition of the gnome-shell architecture in several aspects, is about redefine how components interacts to solved this issue. But not problem, I'm, "Just a stoopid user.", sorry.
Comment 94 Olav Vitters 2017-11-15 22:10:11 UTC
> But not problem, I'm, "Just a stoopid user.", sorry.

Nobody has said anything like this. Secondly, if anyone did they'd get talked to. Everyone here has pretty much the best intentions. Low FPS and laggy mouse sucks. I'd also like this to already be fixed.
Comment 95 Thomas G 2017-11-16 21:29:39 UTC
With the recent launch of Firefox 57 while I was testing it (both on Ubuntu and Android), I randomly arrived on words by Mozilla which totally correspond to our topic here, as far as I understand Gnome 3 being a web-like css gui compositing tool:

(from https://hacks.mozilla.org/2016/02/smoother-scrolling-in-firefox-46-with-apz/ )

"Browsers traditionally handled user input events on the browser’s main event-handling thread. This meant that it could get blocked by pretty much anything else the browser was doing, including running scripts and painting. In Firefox, the Electrolysis (e10s) project separates the content process from the main browser process. This gives us another path for handling input events. Instead of passing the input events from the parent process to the content process to drive scrolling as usual, the input events are used to drive scrolling in the parent process compositor before they are forwarded to the child process for normal processing and dispatch. This is illustrated in the diagrams below."
Comment 96 Lester Carballo 2017-11-16 22:32:06 UTC
Thomas G, you catch the idea and this is a good point. Will be nice to know how to adapted the same idea to this issue. The difference will be the complexity, because there are a toolkit in the middle in this case. Clutter is who really use the libinput backend, not actually the shell (mutter), so if you move Clutter outside of the main process (the compositor) with all it have, will be an equivalent solution to this problem (and also better). An alternative that can solve this issue also is move just libinput outside the clutter toolkit and handled it asynchronous in mutter, but not all clutter itself (just lib input).

The last possibility will also resolved this particular problem of the mouse, but as there are a toolkit working embedded with the whole shell in the same thread, will not be only the input events who can freeze the shell, anything else that occurs in an synchronous way inside the main thread and require some relatively complex processing, will continues blocking the compositor in the present and in the future and this is not nice. Also, you will need to make a hard dependency between Clutter and Mutter with that solution and this mean clutter can not be used outside the a mutter context, with it absurd in my point of view.

Both ideas to handled this was proposed by Jonas Ådahl some comments ago. Anyway, this is pretty complex to be done. Is not a change to the next weekend or something like this. So, that required rethinking first what is more convenient to gnome from the future and also what are the inconvenience in the middle and how difficult will be move all this.

For all this reason i think is  better think it as task to Gnome Shell 4, and not for the next weekend.

Olav Vitters: Thanks for your nice comment. Read the André Klapper main page (https://wiki.gnome.org/AndreKlapper)... My comment was to be friendly with him, not the opposite.
Comment 97 krinkodot22 2018-02-17 05:43:46 UTC
Created attachment 368465 [details]
Key stickiness

One of the things that can cause the screen to freeze is when a popup or tooltip is displayed. Unfortunately, those kinds of things happen quite often while moving the mouse or typing with the keyboard, which directly mucks up your input, like making certain keys get pressed for longer than expected (as people here have already mentioned) or mouse clicks turning into long-presses.

I've attached a brief screencast of key-stickiness in action, which happened while typing in a textbox that provided drop-down completions.
Comment 98 Idan Bidani 2018-03-13 00:48:22 UTC
GNOME Shell 3.26.2
Fedora 27

I've experienced this issue for while and the fix was to uncomment the following line in /etc/gdm/custom.conf
"WaylandEnable=false"

Thanks a lot to https://www.hyperborea.org/journal/2017/11/nvidia-unusable-fedora
Comment 99 Strangiato 2018-03-18 21:42:28 UTC
Still many cursor lags in Gnome 3.28, Arch Linux.
Comment 100 Markus S. 2018-03-18 23:14:02 UTC
(In reply to Strangiato from comment #99)
> Still many cursor lags in Gnome 3.28, Arch Linux.

It definitively got a lot worse compared to 3.26 on openSUSE TW – in fact so bad, it's no longer usable.
Comment 101 Kadir 2018-03-19 06:28:29 UTC
Recently I bought a Latitude 7480 with a 7th gen i5 (7300u) and I still have the stuttering (even with everything at max performance).

Maybe I'm missing something and forgive me for my ignorance, but I still don't get it.

Why not focus the next release of Gnome (version 3.30) solely on performance optimizations en include maybe one or two features (like quarter tiliing)?

And after that, focus on rewriting Gnome Shell (4.0 according to the proposal) and do the next release a year later. I think most users would accept that.

Why not do it?
Comment 102 Leho Kraav (@lkraav :macmaN) 2018-03-19 11:04:51 UTC
I believe the main problem right now is that neither Gnome or upstream people know what exactly the gradual slowdown problem is about, and/or where exactly in the stack it sits and/or how to consistently reproduced it. It's been like this for years.

Some more (probably) relevant bugs I'm following about this

Bug 667456 - gnome-shell becomes slow after a suspend/resume
https://bugzilla.gnome.org/show_bug.cgi?id=667456

ACTIVE Bug 642652 - Major memory leak on mutter when using gnome-shell
https://bugzilla.gnome.org/show_bug.cgi?id=642652

In my case, the Gnome Shell and/or mouse tracking slowdown visibly happens over time. Triggers involved seem to be working with large extended screens (I use 3440x1440 for extended desktop) and for apps, Google Chrome especially seems to somehow contribute to the phenomenon. I've also noticed a clear connection to stutter getting worse and then Gnome Shell soon crashing thereafter (crash trigger can for example be a right-click menu drawing).

But this by no means exhausts the problem vector list, which makes the issue so problematic.

I have not been able to find out with certainty whether anyone in the developer circle is even experiencing any UX degradation, which might be the top reason why it isn't getting fixed for years.

For example, if at the Gnome Shell performance dept nobody has a large monitor (3440p and up, incl. 4K) that they work with every day, I wouldn't be surprised if this degradation never shows.

I'd be happy to participate in crowdfunding a large monitor or maybe even fund it myself if someone just would say they are working on it and only needs more relevant hardware to diagnose and squash the issue.
Comment 103 Anass Ahmed 2018-03-19 13:03:18 UTC
(In reply to Leho Kraav (@lkraav :macmaN) from comment #102)
> For example, if at the Gnome Shell performance dept nobody has a large
> monitor (3440p and up, incl. 4K) that they work with every day, I wouldn't
> be surprised if this degradation never shows.

It happens to me on a 1080p laptop screen (14" inch) with rather capable hardware (Core i7 HQ, 16 GBs of RAM, SSD ... etc). So, it doesn't only happen for high-resolution big screens.

Since I lost my laptop batter, and I had to shutdown the computer more often (instead of just suspending it) .. I started to notice the issue appears less and less, which confirms that GNOME slows down over time (memory leak maybe?).
Comment 104 Kadir 2018-03-19 14:02:03 UTC
My screens (on two laptops and one desktop) are 1366*768, 1920*1200 and 1920*1080 and I have uptimes of a couple of weeks/months with no extra slowdown.

For me the problem is more noticable on Wayland (mouse/animations stutter) but it is also noticable on X (animations stutter, popup menus slow down videoplayback). 

In my situation it has nothing to do suspend/resume and/or long uptimes, the issues are always there.
Comment 105 Strangiato 2018-03-19 14:16:44 UTC
My laptop (i3 3110m, 8 gib of ram) has 1366x768 touch screen and I have many cursor lags immediatelly when I turn on my machine and start Gnome Wayland session. So also nothing to do with large screen or suspend/resume here.
Comment 106 Jakub Szafrański 2018-03-19 14:24:50 UTC
I have a i7-6700HQ, with its integrated GPU (nouveau or nvidia doesn't work well for me, so I'm running the `i915` driver only.), and with 1920x1080 display. And it's also very noticeable.

And same to Kadirs comment, I also notice that gnome3 has very low framerate on X as well, but at least there the cursor pointer doesn't freeze, which I guess makes it not that annoying.

I think there's no point in debating who has what hardware, and if it's really a problem or not. Multiple people with decent hardware reported this issue, so I think it's already acknowledged that gnome3 has performance issues. 

More confirmations on this won't make any difference.
Comment 107 Kadir 2018-03-19 16:15:00 UTC
@Jakub Szafrański You are right.

But the problem is that this bug has existed for a long time. I think the Gnome devs exactly know what the issue is (with regards to this bug, I don't know about the other bugs). It is CPU related, look at comments made by Jonas Ådahl.

Even in the Gnome 4.0 proposal it states that these issues exist and they probably will be solved with version 4.0.

As others have stated I am all for a crowdfunding campaign to make Gnome 4.0 happen sooner than later. I am happy to contribute financially to make it happen.

With every Gnome release (now with 3.28) this bug and the other performance related bugs get some attention because everyone wants to see them solved, but everytime we get disappointed.

Don't get me wrong I very much appriciate the hard work of the Gnome Devs, but work on Gnome 4.0 needs to happen fast. Other DE/WMs (even wayland ones like Sway) do not have these problems.

I am aware that there is a hackfest Performance in May. Let's hope these issues get some attention.
Comment 108 Strangiato 2018-03-24 22:50:28 UTC
I disabled all my shell extensions and now the situation is much better despite some noticeable cursor lags.
However shell became almost unusable because missing features lol.

I noticed another problem since Gnome 3.26.2: shell becomes very slow when unlocked (no high cpu/ram usage is detected) after several hours. When my several extenions were still enabled, shell became so slow after session unlock that a session restart was required to I use shell again. With all extensions disabled, shell performance is also slow when session is unlocked  but it to normal some minutes later.
Comment 109 solarquiet 2018-03-24 23:37:03 UTC
Hi all, 

I have many of the issues you people have mentioned however I did somethings which actually improved the performance (albeit small) in one way or another. The things I did were done on the following configuration

- Intel i3 3227u @ 1.9GHz, Intel HD 4000 12GB of RAM, 240GB SSD, Fedora 27 + GNOME on Wayland

Here is what I did to it and I'll share my experience on it.

- Disable all extensions and if possible, remove them from the shell. Some distributions don't allow for removing certain extensions but that's okay.

- I've stopped using other themes and switched Adwaita. It might be silly to think a theme would affect performance but I believe themes do have some impact on the performance over others. Better to use the theme that was meant for it but I hope this isn't the case for the performance issues. Give it a shot.

- Disable animations if

As of now, I have been running GNOME like this and it's actually pretty smooth when dragging windows around. There definitely is some mouse lag when you open the date or the status menu but it's not bad enough to affect my work. It sucks that GNOME is pretty slow but disabling extensions seemed to help it a *lot*. I know that many of you cannot use GNOME without extensions but it is worth trying and reporting back your findings. This however doesn't solve GNOME's issues whatsoever! It only helps rub it's chest.

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. 

I seriously hope GNOME devs are aware of the performance issues and they do their best to fix it. We don't want to do silly things that affect our workflow just to get it running properly. I want to use the GNOME animations but I can't because GNOME is too slow! I want to use a few extensions but I can't because GNOME is too slow! Please guys, focus on the performance issues with the next release.


Best of luck to the GNOME team.
Comment 110 Jeroen Bollen 2018-03-25 00:22:40 UTC
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.
Comment 111 Anass Ahmed 2018-03-25 03:55:08 UTC
(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.
Comment 112 rk 2018-03-25 12:34:28 UTC
It's definitely not fixed. I haven't seen any change in regards to this bug since GNOME Shell switched to using Wayland by default (don't know if maybe it was even worse before that). And I'm talking about the original issue - laggy mouse movements when interacting with some elements of GNOME Shell (like when opening the app grid, moving the mouse over opened elements, like calendar, weather, in the top-bar) and when opening context menus.

I don't experience any of the later issues being posted here - general performance problems in GNOME Shell (I haven't tried GNOME 3.28 yet though). It seems to me that the discussion regarding those issues would belong in a different bug.

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.
Comment 113 Jeroen Bollen 2018-03-25 17:08:30 UTC
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
Comment 114 mike 2018-03-26 15:41:25 UTC
(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.
Comment 115 krinkodot22 2018-03-27 04:31:55 UTC
(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.
Comment 116 krinkodot22 2018-03-27 04:39:21 UTC
Created attachment 370171 [details]
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.
Comment 117 nw9165-3201 2018-03-31 00:58:57 UTC
(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
Comment 118 nw9165-3201 2018-03-31 01:01:39 UTC
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.
Comment 119 nw9165-3201 2018-03-31 01:05:01 UTC
(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
Comment 120 Christian Stadelmann 2018-05-20 21:09:05 UTC
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.
Comment 121 Jan Vlug 2018-05-21 09:37:17 UTC
Regarding the freezes during notifications, see:
https://bugzilla.redhat.com/show_bug.cgi?id=1539258#c17
I experience this as well on Fedora 28.
Comment 122 Alex Hultman 2018-06-03 13:35:53 UTC
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.
Comment 123 purfett 2018-06-09 09:20:33 UTC
(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.
Comment 124 rsignup 2018-06-29 09:13:57 UTC
I see this issue on Fedora 28 while working with IntelliJ allot, its very frustrating.
Comment 125 Carlo B 2018-07-10 08:51:01 UTC
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/
Comment 126 Daniel van Vugt 2018-07-18 10:00:26 UTC
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
Comment 127 purfett 2018-08-03 03:43:08 UTC
@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
Comment 128 purfett 2018-08-03 09:50:19 UTC
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.
Comment 129 purfett 2018-08-03 12:48:01 UTC
RE-EDIT: I was super wrong. These changes really made some steps forward.
Comment 130 Daniel van Vugt 2018-08-08 01:34:29 UTC
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.
Comment 131 Strangiato 2018-09-13 21:57:24 UTC
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.
Comment 132 Gergely Gombos 2018-10-19 15:11:03 UTC
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.
Comment 133 Victor Zhestkov 2019-01-15 07:40:52 UTC
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.
Comment 134 Alynx Zhou 2019-02-11 12:46:18 UTC
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
Comment 136 pie.or.paj 2019-07-03 14:15:29 UTC
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?
Comment 138 Lester Carballo 2019-08-05 04:17:19 UTC
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.
Comment 139 Daniel van Vugt 2019-08-05 04:53:47 UTC
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.
Comment 140 Lester Carballo 2019-08-05 06:09:48 UTC
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.
Comment 141 Alynx Zhou 2019-08-05 06:25:37 UTC
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.
Comment 142 Gergely Gombos 2019-08-05 06:40:43 UTC
(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.
Comment 143 Lester Carballo 2019-08-05 07:05:08 UTC
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.
Comment 144 mike 2019-08-05 18:24:47 UTC
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.
Comment 145 Lester Carballo 2019-08-06 00:31:02 UTC
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.
Comment 146 Bastien Nocera 2019-08-08 22:44:18 UTC
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.
Comment 147 Daniel van Vugt 2019-08-15 08:39:16 UTC
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.