GNOME 40 Mutter Moves Input Work To A Separate Thread

[oleid]

It's not really THAT hard. Read that book "Java Concurrency in Practice". The very first chapter demystifies and boils down to the essentials - concurrency problems are all about access to the same piece of data from multiple threads. So your job is to protect data accesses and plan for this in advance, when designing and writing software. If you do that, most of your problems will vanish.

Getting multi threading right is doable. Even for complex architectures. Keeping them correct when refactoring the architecture more difficult.

[oiaohm]

libweston and wlroots are not the same thing as X.Org Server. Simply because they are not part of Wayland itself but third party libraries written for making Wayland compositors easier.

libweston is out of the Wayland reference implementation so in fact not 100 percent third party.

If you writing window manager for X11 then you have to use some X11 implementation to run it.

https://en.wikipedia.org/wiki/List_of_display_servers#X11

Hmmm

You need additional software to run your window manager, it's not going to work without X11 middleware.

This misses the early history of X11 where you had Unix writing their own X11 servers with the windows manager welded in.

https://arcan-fe.com/about/ Fun point just because something is a X11 server does not mean X11 Windows managers and X11 Compositors work. Of course we have got use to seeing x.org versions of X11 servers not the other custom ones. Its really simple to forgot early stages of X11 development fragmented a lot this is normal when everyone is free todo there own solutions.

When you are writing Wayland compositor it's slightly different thing. You don't need to install additional middleware to run your compositor but you need to take care about things that X11 did for you. libweston or wlroots would make writing your compositor easier but nothing else - they are not needed like X11 implementation for your compositor to work properly. Not every Wayland compositor are using these projects. If we check the list of popular Wayland environments we will see that two of them (KDE and GNOME) are not using libweston or wlroots but their own implementation of Wayland protocol.

At the start of X11 not everyone used the same X11 server either. KDE and Gnome still user libwayland-server. This process is seeing multi new implementations. This allows multi different solutions to be tried out at the same time.

That was my question for mdedetrich who suggested that GNOME wasn't using multi threaded I/O for 20 years. That's not true if we look at X11 architecture. Metacity (or rest of GNOME) wasn't responsible for processing input so why it should implement this 20 years ago?

https://en.wikipedia.org/wiki/XCB

XCB is 2001 when using multi threads with X11 came possible. Of course due to X11 protocol being a jackass this is not going to give you as much advantage as it should. Action latency could have been lowed in 2004 if Metacity had moved input processing into independent thread when xcb came production usable. Of course this would mean having to solve locking problems.

GNOME started to be responsible for input when Mutter became Wayland compositor.

Not exactly right this is when it started being responsible for other applications inputs. So having bad input handling itself now came spread like the plague. Spitting input handling and rendering handling to make better use of multi core cpus made sense in 2004. Came absolutely lethal problems when Mutter came a Wayland compositor. The extra action latency is clear in 2004 Metacity. I would say had 16 years todo the split not 20. But from 2004-2013 you are only going to see minor gains putting mutter input handling in its own thread due to the limitations of the X11 protocol.

If I recall correctly GNOME started implementing Wayland somewhere around version 3.10 released in 2013. That makes 7 years. Not huge amount of time if we look at another operating systems implementing big changes. For example - it took 6 years for Windows DWM to support software rendering.

DWM is only putting in a compositor not changing major sections of the basic protocol. Quartz from apple is about the same size change as Wayland and it took 13 years to implement.

[dragon321]

The big problem here the middleware of X11 is horrible broken due to the protocol limitations.

Also wayland compositors based on libweston/wlroots.... are using library middlewares. If we could get a proper agreement on what the library middle wares should look like Wayland compositors may not have any more individual responsibilities than WM/DE did under X11 as those responsibilities would go to a library instead that could be spawning off threads/processes as required.

X11 was not broken all the time. When X protocol was created making it that way made sense.

libweston and wlroots are not the same thing as X.Org Server. Simply because they are not part of Wayland itself but third party libraries written for making Wayland compositors easier. If you writing window manager for X11 then you have to use some X11 implementation to run it. You need additional software to run your window manager, it's not going to work without X11 middleware. When you are writing Wayland compositor it's slightly different thing. You don't need to install additional middleware to run your compositor but you need to take care about things that X11 did for you. libweston or wlroots would make writing your compositor easier but nothing else - they are not needed like X11 implementation for your compositor to work properly. Not every Wayland compositor are using these projects. If we check the list of popular Wayland environments we will see that two of them (KDE and GNOME) are not using libweston or wlroots but their own implementation of Wayland protocol.

Wayland is only 12 years old. Yes before Wayland putting the input out on a independent thread was not going to change much when the X11 server was going to turn it all into a single threaded process to the Gnome parts.

Fixing up a core design screw up is long and painful.

That was my question for mdedetrich who suggested that GNOME wasn't using multi threaded I/O for 20 years. That's not true if we look at X11 architecture. Metacity (or rest of GNOME) wasn't responsible for processing input so why it should implement this 20 years ago? GNOME started to be responsible for input when Mutter became Wayland compositor. And it's not even 12 years. If I recall correctly GNOME started implementing Wayland somewhere around version 3.10 released in 2013. That makes 7 years. Not huge amount of time if we look at another operating systems implementing big changes. For example - it took 6 years for Windows DWM to support software rendering.

[oiaohm]

I was trying to make this easy, thank you for clarification. But it's not totally wrong. Wayland compositors are responsible for more things because you don't have any middleware like on X11.

The big problem here the middleware of X11 is horrible broken due to the protocol limitations.

Also wayland compositors based on libweston/wlroots.... are using library middlewares. If we could get a proper agreement on what the library middle wares should look like Wayland compositors may not have any more individual responsibilities than WM/DE did under X11 as those responsibilities would go to a library instead that could be spawning off threads/processes as required.

Wayland is 20+ years?

Wayland is only 12 years old. Yes before Wayland putting the input out on a independent thread was not going to change much when the X11 server was going to turn it all into a single threaded process to the Gnome parts.

Fixing up a core design screw up is long and painful.

[dragon321]

The answer is no that is not correct.

I was trying to make this easy, thank you for clarification. But it's not totally wrong. Wayland compositors are responsible for more things because you don't have any middleware like on X11.

Yeah, took Gnome like 20+ years to realize that you should always be doing UI/input events on a separate thread? This is something that you would find in "GUI programming for dummies" book.

Wayland is 20+ years?

[mdedetrich]

Finally. How many years have we been waiting for this?

Yeah, took Gnome like 20+ years to realize that you should always be doing UI/input events on a separate thread? This is something that you would find in "GUI programming for dummies" book.

[tildearrow]

What is CI? Code input? Commit input? Sorry, I'm a newb.

Continuous Integration.

Automated build and testing systems.

[Xsidm]

The review process and the CI is really good now. Adahl is super picky and thorough. CI happens on commit level, GnomeOS level and distributor level.

Just like upstreams are meant to be.

What is CI? Code input? Commit input? Sorry, I'm a newb.

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.

That's not a feature, it's a bug.

[oiaohm]

So Linux is theoretically closer to a real-time kernel than both Windows and macOS, but in the real world, both Windows and macOS are much more suitable than Linux for audio production and low-latency audio.

This is in fact wrong. There are a lot of users of jackaudio on Linux because they really do need low latency audio for production. I will accept that to get somewhere near a low latency audio is far faster and simpler on Windows and Mac OS. This is why there is a lot of interest in pipewire. Please note this has been a 35 year travelling in reducing sound servers on Linux. Yes sound server problem starts before Linux exists.

Yeah, Wayland have taken forever. I think macOS have had Quartz which is similar to Wayland since forever. Apple quickly migrated from x86 to ARM.

Migrating between cpus is faster than migrating complete software interfaces. Quartz happens year 2000 with the migrations from Mac OS 9 to Mac OS X. There is a huge stack of Mac OS 9 applications that had to be run in emulation for 10+ years. By the way Quartz is older than that it was prototyped in nextstep platform with Display PostScript yes this starts in 1987 so there is 13 years of development before Quartz was production ready following by about another 10 years after that to migrate all the applications.

Core display interface API/ABI development like or not is a multi decade process and hardware is a lot more complex when wayland started. Android interface was one of the fastest but that was still a decade before the design was locked down.

Wayland development speed for a core display interface API/ABI is what you should expect. The progress has not been exactly fast but by compared to speed this stuff is developed in the same area for other operating systems the progress is going quite quickly. There has been a lot of unrealistic expetations for how fast Wayland should develop when you look at histories of how long the other platforms took to develop the same things.

But permissions is something that work on Android today, fully.
On Linux its just oh this one is Flatpak, this one is Sandbox, and the rest is .deb's and executables in /bin/, sure there are infrastructure and plumbing and technology like cgroups in place which could theoretically be used, but it is not used to sandbox everything. It's like "we have all this, and we have this and this and this" but none of it is used. Or like "you have this which we could use to achieve this", but its not achieved. Android has achieved it in the real word long ago.

Except Android has not achieved it for desktop class usage cases so the claim of fully is wrong. Like you don't run Android Studio to develop android applications. So there is a unsolved problem in the Android solution as well.

Cgroups is going though the process of being deployed. There is a weakness in the Android permissions model being application based what do you do when you have 2 users on a system that want the same application to have two different permissions. Flatpak sandbox has been particularly designed to allow a single user or multi users run single application with different permissions. The cgroup model being developed jointly by gnome and kde also include this propriety to run single application multi times with different permissions.

How to secure applications for every use case in a universal way is not in fact a solved problem yet.