Wasn't one of Wayland's key design features combining the window manager and compositor? I am not too familiar with its history but surely there have been presentations or papers about the Wayland designers' reasoning for doing so.

▲

wmf an hour ago | parent | next [-]

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.

▲

csb6 an hour ago | parent [-]

Yeah, 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.

▲

WhyNotHugo 44 minutes ago | parent | next [-]

> It seems like instead of introducing another IPC protocol like this project does

It 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).

	▲	csb6 30 minutes ago \| parent [-]
		Interpreters for Python, Lua, etc. can be embedded so using them does not require a separate process.

▲

sly010 an hour ago | parent | prev [-]

... or the WM loads the compositor, or the WM links to a compositor library (i.e. wlroots). The point is there are options...

Honestly, 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?

▲

diegocg an hour ago | parent | prev [-]

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.

	▲	csb6 an hour ago \| parent [-]
		I was responding to this comment in the article and wondering about the historical context: > 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.