the damn small Wayland API

Wayland 1.0 release is knocking the door and people keep asking “why Wayland if we got X already”, or things like performance, memory consumption, power savings and other kind of advantages on having Wayland instead X. Those are very important points to consider, of course, but for one individual actually programming the graphics system the answer should be straightforward: Wayland API is damn small.

1. But who’s going to program Wayland or X?

Short answer is: very likely you won’t :) A more elaborated answer requires the understanding of what is the graphics system “shell” and its components, or in other words what is the system layer that fits on top of a core graphics system.

While the graphics system comprises of an hardware abstraction, the shell could be thought as an abstraction for such graphics system in a way that application developers would feel more comfortable on writing their applications there – it would be the application software glue therefore, offering convenience for an ordinary developer. Examples of shell components are widget library “toolkits”, game engines, window and decoration managers, Web runtime, video processing libraries and so forth. Developers of these kind of components are the only ones that need to understand the graphics system API, in principle.

2. And what is the X API?

libxcb is the implementation of X11 protocol. libxcb needs 19 functions to deal with IPC related stuff. The core protocol implementation and libxcb protocol helpers export 195 functions all together. All extensions, developed over the 25 years of X existence, sum up 26 in total with 1064 functions for clients. Therefore the X11 client API has approximately a total of 1278 entry points.

Raw data and how I collected it is here.

When we talk about a graphics system, we like to think about the drawing APIs only. It’s a big mistake. The API is more broad, encompassing for instance input methods, input devices, output devices, a bunch of graphics related configuration aspects, testing and so on. In fact, X has basically two drawing APIs (the core protocol and Xrender) and some systems building very modern interfaces are not even using them anymore, bypassing via OpenGLES and friends.

I’ve reported about one year ago that some new systems don’t use the core X protocol and just use a few extensions instead. One would claim that this is alright cause the API would be smaller, but my opinion is if things carry on expanding outwards like they have been, we’re going get to a point where the graphics systems becomes unmaintainable. Moreover, it takes too long for the shell developer learn that just a small set of the API is needed. The X protocol flexibility feature in which developers can add many new extension as desired and the lack of a proper API deprecation mechanism is definitely a problem to consider here.

3. So what is the Wayland API then?

Wayland API has approximately a total of 135 entry points, in its 0.99 version. libwayland solely exports 19 functions, where most are related with IPC, dispatching of events and etc which are the main responsibility of the library. The 14 interfaces consists of 102 functions and usually a client application will require some platform specific routines as well, such as the EGL abstraction and some for the DRM driver model; these add 14 more functions currently.

Raw data here.

We have something we call “private protocols”, that describes more high-level interactions and a few special clients. Examples are the XWayland infrastructure, desktop shell workspace and its panel bar, input methods where special care for device grab is needed and etc. One might consider adding those APIs as well but anyhow, Wayland has a small API after all.

Although X and Wayland’s intention are both to sit between the applications and the kernel graphics layers, a direct comparison of those two systems is not fair on most of the cases; while X encompasses Wayland in numerous of features, Wayland has a few other advantages. In special, in this post I wanted to call the attention for the big advantage the shell programmer has when creating components that aid modern interfaces, where only a small set of functions are actually needed using Wayland.

X API is approximately 15 times bigger than the Wayland one. Here, I’ve only counted the amount of exported functions for clients. I understand that there could be different and more precise ways to tell how big is a graphics system API (e.g counting events received by clients, or Wayland amount of interface listeners, or the window properties of X).

16 thoughts on “the damn small Wayland API

  1. @John Drinkwater

    If you sum the 195 from the core protocol, plus the 19 from xcb, that makes a total of 214. But that’s not important. The important thing is that today’s Wayland can do the same today’s X11, only better and with less cruft. Or put another way: when you trim all the unneeded legacy from X11 you get Wayland (more or less).

  2. The problem is that, if we trim X11, we can’t continue calling it X11, it needs a new name because X11 mandates a lot of functions that, today, are not needed. So let’s trim X11 and call it, let’s say, Wayland… oh, wait! :P

  3. So what? X ran fine with 4 MB or so. I am much more concerned about loosing forward compatibility for stuff that has worked for decades. And network transparency which is actually a very cool feature especially for mobile devices.

  4. Look, nobody is forced to used Wayland. X is not going anywhere, and they can actually coexist nicely.

    So even if everyone everywhere was using wayland, X can stick around for as long as backward compatibility is a desired feature.

    Also, Wayland does not prohibit network transparency.

  5. @Martin > network transparency which is actually a very cool feature especially for mobile devices. <

    Really ? 95% users of mobile devices don't need get mobile "desktop" to other device. Yes, maybe need get other desktop on mobile device client. But this no make problem with use Wayland on mobile device. Simply install x-app expansion running on top Wayland.

  6. @Nick:
    Sorry, having to install an X server (or some X extension to Wayland) to get compatibility is as good as it is when using Windows or Mac. It sucks. Also, if you have it always installed by default, the API which has to be supported is now X + Wayland. So what is the point?
    But there is also the other way round, Wayland clients will not work on X. (Well the toolkit could forever support both, but what is the point then?) This breaks the ecosystem. And for what reason? On the Wayland homepage it says that everyhing could also have been accomplished as an extension to X.

    See, I really like small, nice, and elegant interfaces. But if I think of how Wayland fits in the overall picture, I only see how it makes things less functional and more complicated. e.g. have an extra X app for backwards compatiblity, which will probably bit rot soon. Having toolkits have more backends… Having later some kind of network transparency added back in as a kludge, because people realize that it is useful in a world where there is fast internet everywhere (which is then not fully functional, because it “just moves pixels” and does not offer full integration)

    Wayland is only small, simple, and elegant if you ignore all this.

    Imagine having devices (mobile, TV, wlan router, fridge, …) which instead of having stupid web interfaces could have programs with a nice GUI which you can show on your laptop. One could cut&paste a number from the adress book or drag&drop a movie to the TV or just move the window of the TV player from the mobile to the TV when coming home and a lot more. I cannot think how one can design a display system without network transparency at its core in 2012. Probably Apple has to do it at some point before people realize how cool this is.

  7. The interesting point is that, currently, nearly nobody works with X directly, but always relies on libraries like GTK and Qt. By porting both to Wayland (which, in fact, already has been done), all programs based on them will work both in X and in Wayland. So the compatibility layer will be needed only for old programs, like the ones based on Motif/Lesstif or similar. How many programs do you use that work with Motif?

    1. That’s not quite true. Any program that uses Xlib calls will not work with Wayland (or the part that depends on the call will not work). I’m not sure how many apps do this, but I wouldn’t be surprised if it is fairly common (at least among graphics apps), which isn’t really surprising given that no serious substitute for X has existed for about 30 years.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s