Originally posted by tildearrow
View Post
Announcement
Collapse
No announcement yet.
GNOME 40 Mutter Moves Input Work To A Separate Thread
Collapse
X
-
Originally posted by oiaohm View PostThe answer is no that is not correct.
Originally posted by mdedetrich View Post
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.
Comment
-
Originally posted by dragon321 View PostI 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.
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.
Originally posted by dragon321 View PostWayland is 20+ years?
Fixing up a core design screw up is long and painful.
- Likes 1
Comment
-
Originally posted by oiaohm View PostThe 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.
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.
Originally posted by oiaohm View PostWayland 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.
Comment
-
Originally posted by dragon321 View Postlibweston 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.
Originally posted by dragon321 View PostIf you writing window manager for X11 then you have to use some X11 implementation to run it.
Hmmm
Originally posted by dragon321 View PostYou need additional software to run your window manager, it's not going to work without X11 middleware.
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.
Originally posted by dragon321 View PostWhen 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.
Originally posted by dragon321 View PostThat 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?
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.
Originally posted by dragon321 View PostGNOME started to be responsible for input when Mutter became Wayland compositor.
Originally posted by dragon321 View PostIf 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.
- Likes 1
Comment
-
Originally posted by sandy8925 View Post
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.
- Likes 1
Comment
Comment