3 ms·

> Many members of the Wayland project are trying to prevent going down the same path X11 went down, sucking up more and more features and API surface and becomi

> Many members of the Wayland project are trying to prevent going down the same path X11 went down, sucking up more and more features and API surface and becoming a huge, unstable, buggy mess because of its sheer code size. I would argue that if you sum the code of all the Wayland compositors existing today + all the dependencies required for making them work as a proper desktop - dbus, wlroots, ... you likely have much more code (and thus much more bugs overall) than you had for X11. xorg git repo is 400kloc of C, I've seen projects which were on the order of magnitude of 40 million lines of code and still were able to be managed, so to me "sheer code size" sounds a bit weird. Hell, the main project I work on, https://ossia.io https://ossia.io and on which I do the huge majority of the swdev work alone is nearing 500kloc and it does not feel like a burden.

QUrprUd1nCeicw 4y ago
That's not a good comparison. To get a full picture, you have to compare the X server, all the Xorg drivers, the X client libraries, the X utilities, all the different X window managers and compositors, all the code from alternate X server implementations, etc. X11 desktops are all using dbus too so that one counts for both. All together added up it's significantly more code than Wayland, and that's even considering that the major Wayland compositors try to share as much as possible between the X and Wayland implementations. That is, Mutter and KWin didn't use wlroots. Wayland and X11 are just pluggable backends for them. Go and look there yourself if you want to make your own direct comparison. The Wayland backends are pretty small and they talk to the kernel directly, whereas the X backends have to go through all of that extra code just to talk a complicated protocol to the X server to accomplish the same task. This is different situation for older non-compositing window managers that still use the old X11 drawing primitives. Compositors do all their drawing themselves using direct rendering to the GPU so are able to just swap out the backend without much trouble. That shift was happening in X11 in the years prior to Wayland and it's one of the reasons Wayland is even able to work.

QUrprUd1nCeicw 4y ago

That's not a good comparison. To get a full picture, you have to compare the X server, all the Xorg drivers, the X client libraries, the X utilities, all the different X window managers and compositors, all the code from alternate X server implementations, etc. X11 desktops are all using dbus too so that one counts for both. All together added up it's significantly more code than Wayland, and that's even considering that the major Wayland compositors try to share as much as possible between the X and Wayland implementations. That is, Mutter and KWin didn't use wlroots. Wayland and X11 are just pluggable backends for them. Go and look there yourself if you want to make your own direct comparison. The Wayland backends are pretty small and they talk to the kernel directly, whereas the X backends have to go through all of that extra code just to talk a complicated protocol to the X server to accomplish the same task. This is different situation for older non-compositing window managers that still use the old X11 drawing primitives. Compositors do all their drawing themselves using direct rendering to the GPU so are able to just swap out the backend without much trouble. That shift was happening in X11 in the years prior to Wayland and it's one of the reasons Wayland is even able to work.