I don't have any raw data for performance numbers and that wouldn't matter anyway because they may not be relevant to your set up; if you're concerned about that you should run a test comparing them yourself on your specific environment. I'm speaking in terms of code complexity here, if you want to follow the threaded approach then minimum two threads will do the job (one for the scenegraph, one for the sockets), and an X compositor should potentially be doing this anyway to avoid lag caused by slow rendering. The difference is that the X compositor is just storing a copy of large amounts of state from the X server, whereas the Wayland compositor would store the canonical data and wouldn't need to worry about falling out of sync with the X server.
Also, the way that X does it is overly complicated and is unnecessary to have protection against window manager crashes. A similar type of crash protection could be done with a Wayland implementation and it could be done in a much simpler way than moving the entire window manager out into a separate process. You just need to have another process that can hold the client fds and cache a minimum amount of state needed to resume the clients, it wouldn't need to know as much as the X server does to accomplish that task. Prior art is in the Arcan Wayland bridge, other Wayland implementations have not implemented this but they could eventually: https://arcan-fe.com/2017/12/24/crash-resilient-wayland-comp...
> if you're concerned about that you should run a test comparing them yourself on your specific environment.
I mean, X.org runs well enough on my end? I'm not finding myself wanting something with lower input latency.
> The difference is that the X compositor is just storing a copy of large amounts of state from the X server, whereas the Wayland compositor would store the canonical data and wouldn't need to worry about falling out of sync with the X server.
Honestly, if I were to do a ground-up X11 implementation, I'd probably build it around wlroots or similar. Then Wayland clients could interact with it, and I'd be able to preserve all the X11 compatibility and X11-isms I cared about. Like having separate window managers, hotkey daemons, screenshot tools, the slew of X11 command-line clients I know and love today, and so on.
Someone could build a combined Wayland/X server in the same process like that, but why? The only reason you would need to do that would be to run Wayland clients natively on your X server. IMO if you want to use Wayland it is much easier and more valuable to just port those tools. The hotkey daemons, screenshot tools, and command-line clients are pretty small and not that hard for someone to rewrite as a weekend project, people have done a lot of that already. The harder part is the window managers, but if you're a hard-core window manager author used to doing things the X way then you won't see much reason to switch anyway.
If the Wayland/fd.o crowd insists on breaking things I relied on to the point where I have to work weekends to fix everything that used to work, I'm going to spend that time replacing whatever software they wrote that I use with software that I wrote, since at least I won't be breaking my workflow.
I don't understand what you mean. You can still continue using X if that's what you want, people deciding to spend their time developing Wayland doesn't somehow break X or make it worse.
Also just FYI, it seems x.org has merged with freedesktop.org so they are mostly equivalent at this point, being run by the same group of people.
I'm assuming that X.org will go unmaintained after a time, which is fine. But if that means I can't get a usable X server running later on, I wouldn't mind taking a crack at adding a Wayland extension that implemented the X11 protocol.
It's not clear what that would solve, XWayland mostly fulfills that role already. It can't run window managers, but you wouldn't really get that everywhere from adding another Wayland extension either -- doing that would require a lot of additional code and the GNOME and KDE implementations wouldn't want that anyway because they have their own built in window managers. So maybe you could get a hacked up version of Weston that can run X window managers, but why bother dealing with maintaining that instead of just maintaining X? It's unlikely the X server will stop working as long as you have a GPU that supports GL or Vulkan, the glamor/modesetting driver should continue to work there.
I don't know of any significant applications that are Wayland only. If that ever happened, someone could just make a really simple Wayland server that does the reverse of XWayland.
Also, the way that X does it is overly complicated and is unnecessary to have protection against window manager crashes. A similar type of crash protection could be done with a Wayland implementation and it could be done in a much simpler way than moving the entire window manager out into a separate process. You just need to have another process that can hold the client fds and cache a minimum amount of state needed to resume the clients, it wouldn't need to know as much as the X server does to accomplish that task. Prior art is in the Arcan Wayland bridge, other Wayland implementations have not implemented this but they could eventually: https://arcan-fe.com/2017/12/24/crash-resilient-wayland-comp...