Yearly Wayland Survey
Every year or so, I give Wayland a try. While it’s great to see how it’s progressing, it’s not quite there yet, for me.
- This year, Wayland is both faster and lighter than previously. I’d say that this year, it felt more responsive than X11. This is a big change from the last time I tried Wayland, when it had odd skips and lags. I really like how it feels now, and in comparison, X feels a little laggy. I also noticed less resource use. This is hard to compare, because in Wayland the compositor does so much work, and I was using a new (to me) compositor (Leaf). Regardless, it’s nearly a 1:1 comparison now: Leaf is essentially a functional clone of bspwm, and Leaf+Wayland feels microscopically smoother than bspwm+X11. I also noticed none of the random CPU spikes and higher memory use in Wayland, and in fact it looks like it may be performing better than X in that department.
- Leaf is fantastic. bspwm has some really strange behavior when the display geometry changes, like existing windows assuming bizarre geometry restrictions that I’ve yet to untangle, and it suffers from random crashes unrelated to display geometry (crashes that never happened with i3). I didn’t use Leaf for nearly as long, but it was rock-solid, through display changes and sleep/resume cycles for the couple of weeks I was running it. Leaf is also more intuitive than bspwm, which has odd design decisions like the memory model of windows being mostly tree-like, except when it isn’t. It makes me want Leaf for X11.
- Most of the GUI manipulation tools you’d want are now available: screen shots, geometry management, screen lockers, xdotool, and so on. Almost enough to manage everything.
But it’s still not there.
- Some tools depend on seat management; for example, swayidle expects the WM to have been launched by some display manager, and will not run if you log in to a VT and simply run the WM from there. What if the user doesn’t want a display manager there in the way?
- HDPI is utterly screwed up. There’s a
scale
command in tools likewl-randr
andway-displays
, but it has perverse effects on status bars. Every bar, without exception, got *smaller when the scale was increased, to the point of being illegible. They also got smaller when the scale was decreased, so I can’t imagine what’s going on there – the only time the bars did anything reasonable is when thescale
factor is exactly1
. This means that changing the UI to be “the right size” on a HDPI display is a labor of manually increasing font sizes in every application, which of many cases screws everything up if you drop back into X11. It’s a complete mess. - Some applications refuse to run under XWayland. surf, for one, which makes Wayland a non-starter. That’s not Wayland’s fault; there’s actually a surf fork called surf-wayland, although while that compiles, it also crashes when run under Wayland.
- Most X apps that do work under Wayland are a bit janky, which – for me – meant spending a lot of time looking for Wayland-specific versions. Again, not Wayland’s fault, but it’s a barrier.
So, I’m back in bpswm, which despite the stability bugs and issues that arise during display geometry changes, is still a more usable environment. At least the rendered text at a given font size is the same in all applications.