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

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

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