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.

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.

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.

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).

*** Bug 749783 has been marked as a duplicate of this bug. ***

(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.

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.

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

After around 30min of usage, gnome-shell takes up about 30% of CPU. Then, I experience the pointer lagging as well.
Lenovo T440s, i5

This is still an issue on 3.20, which is a shame, because wayland makes everything else really fluid.

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?

(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.

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.

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.

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.

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.

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?

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.

JS is not the issue in itself, the fact that it is able to stall the C code is the real problem.

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.

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.

Yes, and that's exactly why JS code not blocking the compositor is the solution.

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.

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.

Please discuss this elsewhere, this is not a chatbox. Only post a new comment when you have something valuable to add. Thank you.

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.

*** Bug 774014 has been marked as a duplicate of this bug. ***

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.

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.

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.

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.

*** Bug 775162 has been marked as a duplicate of this bug. ***

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.

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.

No lagging cursor, but bad lag when moving windows, especially if, say, a YouTube video is playing.

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.

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.

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.

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.

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!

(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)?

(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.

(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.

Still many cursor lags on Gnome 3.26...
It's not possible a good user experience until this big problem is fixed.

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.

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

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

No need for confirmation as this happens on every version and every hardware.

So, is there any planned upcoming release when this will get fixed?

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".

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.

> 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 ?

(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).

(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.

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.

> 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.

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!

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.

Please refrain from posting comments that do not help getting a bug closer to getting fixed. There are random other places for that. Thanks.

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

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

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.

(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.

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

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.

(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?

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.

(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.

> 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.

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."

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.

Created attachment 368465
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.

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

Still many cursor lags in Gnome 3.28, Arch Linux.

(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.

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?

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.

(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?).

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.

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.

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.

@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.

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.

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.

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.

(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.

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.

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.