GNOME 40 Mutter Moves Input Work To A Separate Thread

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

[Vistaus]

I hope they make GNOME more robust too. It is not so robust. Sometimes it crashes, sometimes it freezes. Under Wayland that will bring down the whole compositor.

Don't you mean "I hope they rewrite GNOME"? 'Cause in the Genode OS topic, you wrote that all of Linux is shit, so that includes GNOME.

[Vistaus]

Half true: Amiga had preemptive multitasking.

That, and AmigaOS 4.2 will include modern multitasking (4.2 is currently in alpha state).

[Mez']

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

In Gnome on wayland, there's also the issue of dealing with out of control memory over time.

When using Gnome, every few days you need to refresh your session (on Xorg via alt + F2 + r) or RAM goes berserk (3-4x the clean use), but this trick doesn't work on wayland, leaving you with a RAM usage going wild every. single. time. after a while of uptime. I don't want to go through the hassle of saving everything, logging out and back in to solve that. Especially when you have an ongoing workflow.
I just don't understand why they didn't implement this refresh feature in wayland. It's kind of dumb since it's a recurring Gnome issue.

[duby229]

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.



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.




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

Honestly, I'd so much rather have a trick of observation than a totally frozen screen. The fact is, whether you like it or not, Gnome Wayland session "feels" much, much worse than Gnome X session. With wayland under high CPU load the whole session becomes frozen, totally unresponsive. Wayland sessions become just as frozen as Win9x used to become. The -ENTIRE- problem is that the Wayland protocol can -track- input, but it has no means at all to -synchronize- output on input. Input events -need- to trigger output, Wayland has no concept of that.

Even if input was multi-threaded, Wayland will still become totally frozen on heavy loads where all CPU cores are pinged to 100%. Wayland's protocol is totally inadequate for desktop compositors. Wayland's scope is -waaay- too narrow. There is nothing that any compositor can do to make Wayland -NOT- feel laggy. It -will- be laggy because the protocol doesn't have the concepts necessary.

EDIT: Currently most distro's use a cgroups hack to give Wayland compositors maximum CPU priority above all other loads and that can hide input lag on moderate loads. But it doesn't fix the problem, it just hides the problem.

[pal666]

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?

i guess historically it wasn't an issue in x11 mode and it took a lot of refactoring which someone had to do. if you asked why people don't put things into separate threads just in case - because it's slower to write and to execute

[pal666]

this was the one biggest architectural flaw in Gnome, am I right?

this thread already mentions kms updates in main thread. i guess it's flaw of similar size

[pal666]

the Amiga operating system was fully preemptive

op was talking about amiga threads rather than amiga os