Due to design issues relating to implicit sync with wayland any misbehaving app can cause your entire desktop to drop frames so if you're a multi monitor user expect stutters when the browser you have open in the background was a little too slow. Or worse if an app is badly broken [1]
The good news is that all of this is fixable. Windows has forced compositing for most cases and it performs much more consistently. A browser taking a while to render can't hang unrelated windows' composition. Wayland compositors can get there too eventually by moving to explicit sync APIs [2].
For now if you do care about these issues staying on compositorless X is the least bad option.
[1]: https://github.com/ascent12/compositor-killer
[2]: https://www.collabora.com/news-and-blog/blog/2022/06/09/brid...
The basic idea here is that you provide some callback functions the handle events, setup a framebuffer with mmap, and register your surface and framebuffer with the compositor. There is nothing complicated or messy going on here.
This is also the low level interface, most people will not being using this directly and instead will be using a GUI library like GTK or whatever.
I don't know very much C and I have been able to get a "hello world" wayland window setup and displaying some silly graphics with cairo in a few hours or less.
- Wayland can not render strings. You need something external just to render some other text than "hello world". And depending on the library text rendering will look different for each application.
- Wayland can and will block your render loop for arbitrary reasons (like being minimized) potentially indefinitely. In order to make this application useful you have to put everything concerning rendering in it's own thread which complicates things hugely.
- If you want to have basic functionality like capturing the screen (former simple XGetImage() call) you have to talk to dbus and pipwire which pull all kind of dependencies and require loads parallel infrastructure running. And then you still have no guarantee that it works on every compositor.
Wayland is not X11 and doesn't want to be, it doesn't implement even a fraction of what X11 did and that is an intentional design choice!
Wayland does not provide any graphics drawing primitives at all. It only sets up a handle to some shared memory and expects the client to do all drawing.
I think the point here is that you shouldn't be using the display protocol to render text in the first place. If you want to draw text you use a library that is designed for that task rather than shoving that functionality into the compositor and into the Wayland protocol itself.
>- Wayland can and will block your render loop for arbitrary reasons (like being minimized) potentially indefinitely. In order to make this application useful you have to put everything concerning rendering in it's own thread which complicates things hugely.
You don't have to use a thread to do this! You aren't forced to block and wait for the callbacks, you can implement your own event loop and check for messages when you want to!
>- If you want to have basic functionality like capturing the screen (former simple XGetImage() call) you have to talk to dbus and pipwire which pull all kind of dependencies and require loads parallel infrastructure running. And then you still have no guarantee that it works on every compositor.
I think it's good that clients can't capture the screen without permission, and I think using dbus for IPC is very reasonable, but I don't know anything about pipewire or the compatibility stuff.
Also I think it's fair to not like some of these design choices for sure, but it would probably be better for people who like X11's design to continue to use X11 rather than trying to force Wayland into an X11 clone. X11 will be around for a very long time so I don't think anybody will be forced to stop using it any time soon, and people can pick it up if development stops!
Wayland is a display server. Display servers in general do not render strings. They render bitmaps passed in by the clients. Clients are welcome to use their favorite string render libraries into those bitmaps.
> Wayland can and will block your render loop for arbitrary reasons (like being minimized) potentially indefinitely.
Do you realize that all wayland calls are async? On the client side, you don't have to block on waiting on empty socket, if you do not want.
Few conmmens above, someone complained that a basic wayland client is complicated. The complicated thing was... setting up an event loop.
> If you want to have basic functionality like capturing the screen (former simple XGetImage() call) you have to talk to dbus and pipwire which pull all kind of dependencies and require loads parallel infrastructure running.
Yes; but these dependencies are in different processes, not yours. From the POV of your process, it is just an structured IPC.
XGetImage() is not that simple; it only coincidentally worked due to implementation detail. Having a global framebuffer is not mandatory, just at the time all the PCs had it. Nowadays, even PC hardware is getting overlays, so there might not be a buffer that represents what's on the display anymore.
Another issue is, that it is impossible to implement zero-copy screen casting with XGetImage(). It is possible and has been done with wayland and dmabuf, feeding the screencasted surface into hardware video encoder (without the buffer bouncing between system and GPU ram several times), and the userspace getting already compressed video stream.
Final issue is, that XGetImage() is not gated via user permission and does not provide indicators, that the screen was grabbed or is being casted. Wayland does.
Now the separate X11 displays do not have this limitation, but they have other ones: like not being able to move your window from one to another, without restarting the app. Historically, there was only one app, that was capable of changing the display without restart: XEmacs. For all the others, I have my doubts, that users would accept such limitations.
Now, both Xinerama and Xrandr standardized on using X11 screens for multi-monitor displays for exactly this reason. With displays roughly with same DPI and the graphics becoming truecolor, it wasn't really problem. But nowadays, it is.
That is mixed-DPI hardware. Another issue with your argument is, that "DPI and pitch information is accessible via xrandr extension". Yes, it it, that is true. The problem is, that it is one-way street. The client can read that, then it can respect that and adjust its rendering... but it doesn't have to. The client is free to ignore all that. Now the display server has the problem, that it doesn't know, how the client decided: should it upscale the client, or not? Nobody knows, all the display server has is an opaque bitmap.
With wayland, the client must explicitly set the scale, communicate it do the display server, so then the compositor knows, how to handle that surface. It can even transparently downscale the surface, when the user moves it from HiDPI to normal-DPI display. Something impossible on X11.
And no one cares about standardization and development. They just want to use their blasted laptop. I don't know about any of that stuff, I just know Wayland works better out of the box.
You are talking about a very rare niche case where one monitor runs with VRR and the other doesn't. Everything else is handled just fine with X.
> screen tearing.
"No screen tearing" just means forced vsync which is easily possible on X11 with a configuration switch or by using a compositor. Actually forced vsync is one of the great disadvantages of Wayland because it always comes at the cost of higher latency.
> Wayland rocks those two challenges.
And it sucks in every other challenge. Most importantly standardization and development. The Wayland API ecosystem is ultra developer unfriendly and complicated and will pose serious harm to the FOSS landscape which thrives on hobbyist and niche applications. It's so bad it wouldn't be far fetched to call it sabotage. (E.g. look at the hello world: https://github.com/emersion/hello-wayland/blob/master/main.c it's a complete mess)