Similarly, tearing gets pixels to the screen faster.
> There are many race conditions that must be dealt with in input and window management because of the asynchronous nature of event handling. [...] However, not all race conditions have acceptable solutions within the current X design. For a general solution it must be possible for the manager to synchronize operations explicitly with event processing in the server. For example, a manager might specify that, at the press of a button, event processing in the server should cease until an explicit acknowledgment is received from the manager.
[1] https://web.mit.edu/6.033/2006/wwwdocs/papers/protected/xwin...
https://donhopkins.medium.com/the-x-windows-disaster-128d398...
https://news.ycombinator.com/item?id=22491561
https://news.ycombinator.com/item?id=15035419
https://news.ycombinator.com/item?id=28522534
https://news.ycombinator.com/item?id=44045304
https://news.ycombinator.com/item?id=29964737
https://news.ycombinator.com/item?id=15327339
https://www.donhopkins.com/home/catalog/unix-haters/x-window...
https://blog.dshr.org/2024/07/x-window-system-at-40.html
David Rosenthal wrote:
>There is a certain justice in The UNIX-HATERS Handbook's description of my efforts:
Ice Cube: The Lethal Weapon
One of the fundamental design goals of X was to separate the window manager from the window server. “Mechanism, not policy” was the mantra. That is, the X server provided a mechanism for drawing on the screen and managing windows, but did not implement a particular policy for human-computer interaction. While this might have seemed like a good idea at the time (especially if you are in a research community, experimenting with different approaches for solving the human-computer interaction problem), it can create a veritable user interface Tower of Babel.
If you sit down at a friend’s Macintosh, with its single mouse button, you can use it with no problems. If you sit down at a friend’s Windows box, with two buttons, you can use it, again with no problems. But just try making sense of a friend’s X terminal: three buttons, each one programmed a different way to perform a different function on each different day of the week — and that’s before you consider combinations like control-left-button, shift-right-button, control-shift-meta-middle-button, and so on. Things are not much better from the programmer’s point of view.
As a result, one of the most amazing pieces of literature to come out of the X Consortium is the “Inter Client Communication Conventions Manual,” more fondly known as the “ICCCM”, “Ice Cubed,” or “I39L” (short for “I, 39 letters, L”). It describes protocols that X clients must use to communicate with each other via the X server, including diverse topics like window management, selections, keyboard and colormap focus, and session management. In short, it tries to cover everything the X designers forgot and tries to fix everything they got wrong. But it was too late — by the time ICCCM was published, people were already writing window managers and toolkits, so each new version of the ICCCM was forced to bend over backwards to be backward compatible with the mistakes of the past.
The ICCCM is unbelievably dense, it must be followed to the last letter, and it still doesn’t work. ICCCM compliance is one of the most complex ordeals of implementing X toolkits, window managers, and even simple applications. It’s so difficult, that many of the benefits just aren’t worth the hassle of compliance. And when one program doesn’t comply, it screws up other programs. This is the reason cut-and-paste never works properly with X (unless you are cutting and pasting straight ASCII text), drag-and-drop locks up the system, colormaps flash wildly and are never installed at the right time, keyboard focus lags behind the cursor, keys go to the wrong window, and deleting a popup window can quit the whole application. If you want to write an interoperable ICCCM compliant application, you have to crossbar test it with every other application, and with all possible window managers, and then plead with the vendors to fix their problems in the next release.
In summary, ICCCM is a technological disaster: a toxic waste dump of broken protocols, backward compatibility nightmares, complex nonsolutions to obsolete nonproblems, a twisted mass of scabs and scar tissue intended to cover up the moral and intellectual depravity of the industry’s standard naked emperor.
That's an easy way to excuse bad design. Look at the designs of other operating systems designed by professionals and you won't see windows managers having to handle raw inputs or being in the same process as the compositor.
https://en.wikipedia.org/wiki/Desktop_Window_Manager
The Desktop Window Manager is a compositing window manager, meaning that each program has a buffer that it writes data to; DWM then composites each program's buffer into a final image.
https://web.archive.org/web/20040925095929/http://developer....
The Quartz Compositor layer of Mac OS X comprises the window server and the (private) system programming interfaces (SPI) implemented by the window server. In this layer are the facilities responsible for rudimentary screen displays, window compositing and management, event routing, and cursor management.
The window server is a single system-wide process that coordinates low-level windowing behavior and enforces a fundamental uniformity in what appears on the screen. It is a lightweight server in that it does not do any rendering itself, but instead communicates with the client graphics libraries layered on top of it. It is “agnostic” in terms of a drawing model.
The window server has few dependencies on other system services and libraries. It relies on the kernel environment’s I/O Kit (specifically, device drivers built with the I/O Kit) in order to communicate with the frame buffer, the input infrastructure, and input and output devices.
Window management on MacOS is done by Dock which talks to Quartz Compositor where the underlying windows live.
I don’t know how GPU acceleration would have fit in, but I bet it would have been trivial provided the drivers were sufficient.
All of Rio in Plan9 is 6K lines of code and it’s a more powerful display protocol and window manager (all of the fundamentals are there but none of the niceties) than anything else I’ve ever seen.
The defacto way to remote into a Plan9 system from any OS even today is to use a client side program which implements it all the same way Plan9 does.
You need this amount of control to be able to properly filter and secure things. Wayland actually learnt that from X security extensions failure.
To me, Wayland failures are more on the organisational and change management part. In inside, it would probably have been better to provide a core library rather a reference implementation. Also, a lot of pieces needed to fall into place once the ball started rolling and some of them like PipeWire took quite some time to be ready.
The sorry fragmentation and complete unwillingness to work together of the various Linux DE also didn't help. I think Gnome constant NIH syndrome and overall capture of Freedesktop has a lot to do with where we are.
For those who want to complain how lack of choice between multiple implementations is an obvious problem and deviates from UNIX tradition, please wait until the next systemd thread.
