I'm the (mostly negligent) original author of waymonad.
Minor GC stalls are not an issue for reasonable framerates right now.
Major stalls are in the order of a single frame. Which I considered acceptable, but YMMV.
I fully agree on the issue with restarting. I had some ideas about how to improve that, but never got around to doing any of that.
wlroots was my choice, because I like the guys and worked with them on the project. Other libraries (most relevant probably libweston) are a bit more "fully featured" but also slightly less flexible.
> I fully agree on the issue with restarting. I had some ideas about how to improve that
Can you perhaps share some of those ideas? Might be something I haven't thought about. :-)
> wlroots was my choice, because I like the guys and worked with them on the project. Other libraries (most relevant probably libweston) are a bit more "fully featured" but also slightly less flexible.
Is that still the case today? I mean, I haven't really spent any considerable time researching the Wayland landscape, but I was under the impression that wlroots gained considerable momentum in recent years while weston is still just the reference compositor, but not really used in any well-known Wayland compositor.
I've been out of the scene for a couple years now (essentially since I switched from student to full time), but it's mostly the goals.
wlroots is the de-facto standard library used by almost everything but the big 3 DEs. But it's still designed and intended to be mostlyl bare bones, and doesn't have a scenegraph or other nice things.
OTOH it got stuff like damage tracking and I think there were plans to add an optional library on top for some scenegraph stuff.
My main idea around persistance was a wrapper core code, that loads the higher level library. So we could switch out the library as object inside the main code.
At the same time, I'd have used this chance to experiment with hot-path loops that avoid the Haskell runtime, but run in native code. To avoid the previously mentioned GC stalls.
Though in practice, that gets closer to the X model, where we split the display server and window manager with a proper API.
We'd still have more control on what we want async and what we want sync. And it'd be up to experimenting how much of the display manager should be exposed as library functions or just driven from the outside.
Other ideas like serializing state and passing that in some way could work to some degree, but are probably not worth it. Maybe with some help from CRIU stuff, but I'm unsure about OS portability of that.
In general, the big learning I'd like people to take, which is mostly unrelated: don't try to do multi-seat. xmonad has a neat design, and the attempt to add multi-seat broke so much stuff. It's not worth it for a probably <.1% feature.
Out of those persistance ideas, I'm still very much in favor of simply separating the compositor/WM into separate unix processes. Feels like the right thing to do.
I'm the (mostly negligent) original author of waymonad.
Minor GC stalls are not an issue for reasonable framerates right now. Major stalls are in the order of a single frame. Which I considered acceptable, but YMMV.
I fully agree on the issue with restarting. I had some ideas about how to improve that, but never got around to doing any of that. wlroots was my choice, because I like the guys and worked with them on the project. Other libraries (most relevant probably libweston) are a bit more "fully featured" but also slightly less flexible.