GNOME 40 Mutter Moves Input Work To A Separate Thread

[dylanmtaylor]

I absolutely love how much more responsive GNOME has gotten in recent releases. GNOME 3 used to be so ridiculously slow and painful to use.

[lakerssuperman]

This is amazing. One of my last and largest issues with Gnome on Wayland is the laggy cursor. If this change fixes that issue, I think I will finally be on Wayland full time!!

[spykes]

JackLilhammers Why PopOS?

PopOS adds cherry above the Gnome cake, it often implements features that was rejected from the Gnome team (for no good reason).

[sabian2008]

Is this only for Wayland?

[dragon321]

Is this only for Wayland?

On X11 it's X Server job to handle input and window manager/compositor is separate process. On Wayland compositor does everything that X Server does so it needs to handle input as well. Obviously such patches are not needed for X.Org session.


Finally. It was probably one of the biggest (if not biggest) flaw in GNOME Wayland session. It was very annoying seeing cursor lags with heavy IO. I hope it will be finally gone with these patches.

[oiaohm]

I was using multi-threaded applications on the Amiga days... What happened - why isn't important and critical things not in separate worker threads already?

Problem is it not broken don't fix it.

Gnome started 1997 Intel Pentium II time frame this is a single core cpu right. Go back with X11/x.org server it also starts on single core cpus. Horrible as it sounds on a single core cpu the best performance is not separate worker threads but single threaded. So at the start of both of these projects it not broken to go single thread and separate workers on the systems they started on was going to use more cpu time so perform worse back then.

Then everything slowly but surely builds on top of this framework. Now you have something in your project like the Giant lock https://en.wikipedia.org/wiki/Giant_lock what Linux world would big kernel lock. Where different code all of the place depends on the fact that what is in the single threaded is basically locked against itself and will only happen in that exact order. Remember linux kernel had to write a tool lockdep https://www.kernel.org/doc/Documenta...dep-design.txt to dig themselves out of stack of single thread code at its core. Yes early Linux kernel also started on single core cpus so single threaded core parts was right.

This is one of these problems where the choice at the start is right but over time it comes wrong and the nightmare is that its not a little wrong you have dug yourself into a complex hole where you have implement locking as well as working out what parts can truly be run without locking against each other. Lots of fun cases of dead locks for anyone attempting to fix this problem to over come as well.

Notice Linux kernel had to make lockdep. Did gnome need to make a tool as well kind of it was adding support to sysprof to handle the core shell of gnome(kind allows you to see where a deadlock is).

Basically easy to create very hard to dig you way out of. All giant lock problems are multi year fixes and are like to be ignored by developers as they go and do other easier work Gnome is not a special case here.

[oiaohm]

Okay, we now know your love for Amiga lol. Sadly, it wasn't impressive enough to have gone anywhere. You can cuddle it in a blanket and rock it to sleep if you want.

http://www.aros.org/ Not quite it was impressive enough to have a clone maintained right up today.

[JackLilhammers]

JackLilhammers Why PopOS?

More than one reason actually:

• When I try out something on Linux I usually do on Ubuntu based distributions
• PopOS is more user friendly for Nvidia and Optimus laptops
• I'm not a huge fan of Fedora
• There are lots of other options available, but IMHO for testing just Gnome is not worth exploring alternatives

[oiaohm]

On X11 it's X Server job to handle input and window manager/compositor is separate process.

The answer is no that is not correct.
http://software.cfht.hawaii.edu/man/x11/XInitThreads(3x)
Horrible reality if you don't call XinitThreads x.org server from your windows manager and compositor(if you have one) x.org gets to go back to being pure single threaded supply of stuff to the windows manager and compositor.

On Wayland compositor does everything that X Server does so it needs to handle input as well. Obviously such patches are not needed for X.Org session..

Not exactly. You may have mouse pointer moving correctly(because of X.org server drawing it) but you can have a lot of action lag because windows manager/compositor don't have their input handling running on a different thread to the other processing so there are extra delays on input. Wayland really just makes this fault in face and show stopper. X.org server masks over it a bit but is not a 100 percent cure if you are getting into low latency response requirements.

Finally. It was probably one of the biggest (if not biggest) flaw in GNOME Wayland session. It was very annoying seeing cursor lags with heavy IO. I hope it will be finally gone with these patches.

Yes biggest in the face flaw with Gnome Wayland but its a problem in design that also effects X11 users just less human noticeable due to how humans work. Its the fun one confirmed by studies that you can take 1/3 longer for your application starting by adding a splash screen to entertain human and the humans will say it faster when by wall clock it slower. X11 server keeping the mouse cursor moving entertains the human so the human take longer to notice that action processing is stalled out. Giving users good UX experience is part these distractions so users don't notice what is happening really. Of course you will have some highly observant will will see straight though the magic trick slide of hands

[rastersoft]

Amiga had a cooperative multi threading model and no memory protections. That allows a whole lot more performance at the cost of security, which also allowed the Amiga to punch above it's weight.

Half true: Amiga had preemptive multitasking.