The X API Is About 15 Times Bigger Than Wayland

[smitty3268]

What will compiz fusion do for the raspberry pi? It doesn't have enough CPU horsepower to run a compiz fusion desktop. THAT is where the bloat is, ON THE DESKTOP, NOT the X server.

I'm NOT arguing against wayland, I think it's great! But BLOAT is not the reason to switch.

If BLOAT was a legitimate reason to dump software then Windows would have been toast decades ago.

You misunderstand the benefits of removing all these API entrypoints.

It doesn't have anything to do with saving a few bytes of memory - it's about making the developers more efficient. Letting them add new features quicker, fix bugs more quickly, etc. That's a lot harder to do on a codebase with thousands of entry points, 95% of which are extremely poorly tested and hardly ever used, which has decades of hacks built on top of hacks. That's what the benefit is.

Much of what X does has just been moved into the kernel, libdrm, and mesa anyway, so it's not like anyone should expect wayland to approach X. The whole point of wayland was to get rid of the stuff that nobody used anymore or that had already been moved elsewhere in the graphics stack but was kept around for backwards compatibility requirements.

[alanc]

There's probably a good argument to be made that Wayland can be(going forward) smaller and leaner than X is including the same features, or even adding in new features. But we aren't there yet.

Right now, it's simply a matter of Wayland does less, so it's smaller. X does more, so it's bigger.

A good bit of the difference is simply breaking up the functionality differently - X has API entry points for all the drawing routines, font handling, etc., though most modern apps don't use those. In the Wayland world, instead of baking that into the core API, you simply use complementary API's instead, such as Cairo, OpenGL, FreeType, FontConfig, etc. - for a direct functionality comparison you'd add all those to the Wayland count, but as they're modularized better they're easier to maintain and evolve as separate API's instead of hardcoded into the core like X11 did.

[JanC]

It would be possible to cut all the (almost) unused legacy stuff from X too; you would just have to call it X12 instead of X11...

[JS987]

A good bit of the difference is simply breaking up the functionality differently - X has API entry points for all the drawing routines, font handling, etc., though most modern apps don't use those. In the Wayland world, instead of baking that into the core API, you simply use complementary API's instead, such as Cairo, OpenGL, FreeType, FontConfig, etc. - for a direct functionality comparison you'd add all those to the Wayland count, but as they're modularized better they're easier to maintain and evolve as separate API's instead of hardcoded into the core like X11 did.

Wayland is useless. Cairo is using XRender, which isn't supported by Wayland.

[alanc]

It would be possible to cut all the (almost) unused legacy stuff from X too; you would just have to call it X12 instead of X11...

But if we were doing a whole new, compatibility breaking, major release of X, such as X12, we'd want to take the opportunity to examine & redesign many other things about the protocol as well, not just dump the legacy calls. It would probably take some experimenting to figure out what works, and would need to be developed in parallel with X11 for a number of years, so that we didn't abandon all our existing users while designing for the future. In fact, it would probably be best to reduce confusion by not calling it X12 before it was ready, so people didn't think they could upgrade right away and get something better, but to develop it at first under a code name, perhaps the name of a town near the MIT campus where X was originally developed - maybe "Wayland"?

[F i L]

Wayland is useless. Cairo is using XRender, which isn't supported by Wayland.

Yes it is supported. This is what the XWayland project is all about. Eventually, Cairo and other libraries that rely on XRender will need to upgrade to OpenGL. This is a good thing as XRender is already dying off today, and OpenGL is a cross-platform standard. Having a single, cross-platform API is a much better design for developers.

I don't know a whole lot about GPU driver development, but my guess is that eventually these API simplifications will make the closed-source AMD/nVidia drivers much more stable (once Wayland support actually happens). That would be awesome, because currently one of the biggest issues with Linux vs Window/Mac is poor driver support/performance on some hardware (I'm looking at you AMD).

[blackout23]

Hopefully it's 15 times more awesome, too.

[daniels]

Wayland is useless. Cairo is using XRender, which isn't supported by Wayland.

Cairo's 'image' backend uses Pixman to do all the rendering - same as the server's software implementation of XRender.

There is one key difference though: using image and uploading the result via SHM is typically quicker (often much quicker) than using XRender, either accelerated or not. The only platform where it's reliably not so is SNA on Intel, which still isn't the default.

Thanks for your insightful post though.

[nnine]

The only advantage of Wayland seems to be to get rid of some old APIs in X which are not used in modern programs. The problem is, those are required for backwards compatiblity. So instead of having to keep around a few old APIs, a switch to Wayland means that now Wayland + X has to be maintained (X for backwards compatiblity). This is making things more complicated instead of simpler. There is not even a very good reason for this, as the same things could be accomplished by extending X, as they admit on their FAQ:

> It's entirely possible to incorporate the buffer exchange and update models that Wayland is built on into X.

Of course, Wayland proponents would say that I am spreading FUD, but to me the disadvantages are rather obvious: If X is kept only has a backwards compatiblity option, it will bitrot and eventually be removed from the default install. At that point, backwards compatiblity will defacto be lost. Also, forward compatiblity is immediately lost for all programs which rely on the Wayland API. They will not work with X. Maybe common toolkits will support both protocols for some time to mitigate some of those effects, but this too makes things more complicated instead of simplier.

For new programs, network transparency will be lost. Maybe some people do not see any point in network transparency, but I use it every day. With internet everywhere this is actually a feature which gets more useful and interesting in time. Also, people just do not seem to realize how cool this feature could be, if it would be further exploited instead of hidden from the user. Imagine moving a window of a running movie player from a mobile device to the TV when coming home... or all kinds of interactions which could be designed when people could move the windows of their computers to a common display and then the programs could interact by drag and drop or cut&past or whatever. Or just accessing your running X session from any device whatsoever and pick up work where you left. To me, the complete notion that programs run in a specific device and can only interact using the display of this device seems rather limiting and from pre-internet times, but this is exactly what switching to Wayland means for the future. Ofcourse, the common trend in GUI development on Linux seem to be to dumb things down, instead of letting the user fully exploit the technical potential of their system. In that sense, I can see that some people might think that network transparency is just not needed. I guess to some being able to play 3D shooters in a rotating window or similar useless crap is cool enough.

[Ex-Cyber]

For new programs, network transparency will be lost.

Network transparency will be lost at the display server. There's no reason it can't be built into higher-level toolkits/frameworks.