When the window manager is a separate process with async communication between the WM and display server things can get out of sync for a frame or two which leads to visual artifacts. In Wayland the window manager works synchronously with the compositor so that it's never out of sync.
replyYeah, that makes sense. It seems like instead of introducing another IPC protocol like this project does, there could be a compositor that loads different window managers as plugins. Then everything is in the same process and there is no need for async communication. Of course a crash in the window manager would take down the compositor, but this is already true for Wayland compositors that combine both.
reply> It seems like instead of introducing another IPC protocol like this project does
replyIt doesn't introduce a new IPC, it uses the Wayland protocol with the river-window-management-v1 extension. The extension mainly defines new objects and verbs for them, but it's the same protocol.
Separate process means that the window manager can be written in any language (even, e.g.: Python).
Interpreters for Python, Lua, etc. can be embedded so using them does not require a separate process.
replyWhat about Emacs? That's the usecase I care about. Until I can get Emacs to manage my Wayland windows ala EXWM, I'm sticking to X.
reply... or the WM loads the compositor, or the WM links to a compositor library (i.e. wlroots). The point is there are options...
replyHonestly, every time this topic comes up, I feel like the person complaining just doesn't want to put in the work and they are angry that they don't get an easy win. And maybe that's a good thing. Do we really need more half baked WMs?
Well, that's exactly what the article is about. Wayland put all together into one process I order to avoid unnecessary context switch. This protocol aims to keep the performance advantages of Wayland without giving up on separation of graphics c server and window manager.
replyI was responding to this comment in the article and wondering about the historical context:
reply> Although, I do not know for sure why the original Wayland authors chose to combine the window manager and Wayland compositor, I assume it was simply the path of least resistance.