Wayland is a pretty cool project. Its often characterized as an “alternative” to the X11 system. This characterization is made by people who don’t know a ton about graphics environments and don’t realize just how flexible Wayland will make graphics for programmers. I’m going to try my best to explain in the vernacular what makes Wayland so dang cool….
The X11 system really is based around network-based graphics interactions that look like a 1997 Windows box. This is all well and good. The system was designed around 2D graphics with 2d graphics hardware. It was designed superbly. Superbly for 1997 graphics requirements. Over time, 3d graphics became more and more superfluous, and the way graphics was used changed more and more. X11 had more and more holes punched in its API and extensions to accommodate the way 3d hardware operates, and to provide programmers with what they want to do, provide good 3d graphics to the users. This left us with a huge, sticky, complicated mess in X11.
Wayland is designed around a 3D based API (OpenGL) and treats programs with a lot more trust. It will also allow programmers easier access to 3D graphics, and will provide the good developers with full and complete control over each and every frame.
Wayland does all these cool things by only operates on buffers. It abstracts the desktop into just a bunch of buffers owned by a bunch of different programs. It doesn’t care (particularly) where the buffers come from, if they’re 2d or 3d, they’re just graphics buffers. It gives a special client, the compositor, the task of putting all these buffers together on the screen. Any application can do whatever it wants with its buffer, and the compositor can do whatever it wants to put them all on the screen!
This forgoes all the concepts that tie desktops to the 2d design. It just allocates and manages how much memory a program needs, and hands the buffer to the program to fill up with graphics in however and whatever the program wants. This is powerful. Do you have access to an OpenVG api? You can render to the buffer with that api. You could use an OpenGL card to render, you can fill the buffer up with the CPU. You can render anything you want in the buffer, without having to fiddle with GTKglext or similiar layers.
When the program (like Thunderbird) is done with its buffer, it simply can tell Wayland, “Hey! I’m done with this frame!”. Wayland then takes the buffer, and operates on all its registered buffers to create the final product. Lets use an example. You have Firefox, Pidgin, and a notification window that are running. All of these got their graphics memory from Wayland, and fill them up the way they want to. Firefox draws your homepage. Pidgin draws your contact list, and the notification thing draws it message. All three say “hey Wayland, I’m done!”. Wayland then takes all 3 images, and composes them together however its compositor dictates. The compositor is nothing more than a Wayland client, the one that controls the framebuffer. Now, you could make a compositor that looks like your normal 1997-era desktop environment easily. Cool beans. But you can also make something that looks and feels like a multitouch smartphone! You could just as easily make crazy things like, wrap each window around a 3d ball, and have all your windows bouncing around your screen. When you click on a ball, it opens up flat on your screen for you to work with. Any of the slick Minority Report-like UI’s in the movies would be relatively easy to make. The kicker is all of these environments would be equally easy to code.
You’re gonna see some cool things once Wayland overcomes its hurdles. Wayland has some drawbacks and hurdles, which I’ll blog about later. I think none of these are strong enough to stop Wayland, a system like this is needed for modern graphics environments. Hopefully the project can take this momentum and reshape the way Linux appears to its end users.