This book is about Wayland. But Wayland has been built to replace the X Window System. So this chapter is a bit about X to see why Wayland is considered necessary.
The X Window System is designed as a distributed system. Clients communicate over TCP/IP (or similar) with an X Window server. The server is responsible for managing the hardware: mouse, keyboard and video display. Clients are responsible for application content and requesting a user interface.
In general, a number of clients will be making requests of the X server: a browser, an email program, a terminal emulator, etc. These have to be managed in some fashion.
Contrary to what might be expected, the X server does not do this management. The X philosophy separates policy from process, and to have the X server impose process would be against this. (This is in contrast to other window systems.). Instead, another client application is used. This is called a window manager, because it ... manages windows. It is responsible for placing windows on the screen (through requests to the X server), moving them, iconifying them, etc.
There is support within the X protocol for window managers: a client can request of the server that it sends requests to map windows to itself as an X event. The window manager client can then decide what to do with the request. A client can also change the parent of any window - that way it can decorate the window with menu bars, etc.
A composting X window manager is just a classier version of a window manager. Firstly, it gets other clients to draw into a off-screen buffer instead of directly to the video buffer. Then it can play games with the client's image before displaying it. Such games can include mapping it onto a sphere or a wall, making it wobble, etc.
Compositing window managers cause a problem for X servers. The model of event handling is that the X server can work out which window events occur in, and can send those events to the client which owns the window. But a compositing window manager is manipulating an off-screen copy of a client's windows, and what it sends to the server may bear little relation to the client's original windows. Just think of 'wobbly windows': an event occurring while the compositing manager is shaking it around is very hard for the X server to work out who it is for.
Many composting window managers began to bypass the X server and talk directly to the hardware using OpenGL. These include Compiz, KWin and the Quartz Compositor.
In standard X, you can draw solid lines, fill areas such as rectangles, etc. The render extension adds a number of capabilities to this
While these introduce some complexity into the X server, they also typically result in more work done by the client application.
In standard X, fonts are managed on the server. To get font information, a client will make requests of the server. With things like the rise of Unicode (with over 100,000 characters), having to extract this from the server is slow.
The font server XFT is now accessible directly by clients which can perform their own calculations more easily. In particular, it has become common for the them to produce glyphs which are sent to the X server, rather than expecting the server to create them itself.
These changes have all resulted in the X server doing less real work, and just being a bottleneck that all messages have to pass through.
Copyright © Jan Newmarch, jan@newmarch.name
If you like this book, please contribute using Flattr
or donate using PayPal