Hacker News new | ask | show | jobs
by saurik 214 days ago
It isn't particularly easier to make your own compositor either, as you now also have to bring your own window manager. What made the X architecture much more interesting is that it avoided coupling the window manger to the compositor. Hell: there even are multiple popular compositors for X, as they also managed to avoid coupling the compositor to the display server (which would be the one part of the system that you don't find too many of -- though there were multiple implementations over the years! -- but that's not really much different than Wayland where everyone is using the same library to implement the behaviors as part of their coupled-together balls of mud.)
2 comments

>What made the X architecture much more interesting is that it avoided coupling the window manger to the compositor

This is the industry standard, putting the compositor and window manager in separate processes.

Android separates SurfaceFlinger and WindowManagerService.

iOS separates quartz compositor and springboard.

Windows separates dwm and explore.

MacOS separates WindowServer and Dock.

Dwm is both the compositor and window manager in Windows. It’s the same with WindowServer in macOS.

If you are talking about the shell or task switcher, then yeah your point stand with Gnome but KDE has kwin and plasmashell processes.

Tell that to the Wayland people? ;P
But why would I ever want to have a separate compositor and window manager? Like the display stack benefits from "vertical integration", being modular is a tradeoff, often of performance and significant complexity.

Why not just make a display server (which handles everything rendering related, compositing included), and then add a window manager as a plugin/extension on top? Window managers are not that complicated.

I dunno: I have never ever wanted to make a compositor -- which, to me, feels like a really boring piece of graphics infrastructure -- and yet I have used multiple window managers over the years and have absolutely wanted to make my own window manager? In X, making your own window manager was so popular of an activity that it honestly felt kind of unreasonable just how many window managers existed, and yet everyone used one of a handful of compositors and I'm honestly not sure why anyone in their right mind would bother making their own display server?
for instance as a X11 user I don't want a compositor at all
(Same... I know people use them to get some pretty effects; but, they add a frame of latency I do not want and require lots of memory and assume acceleration I don't need.)
There is no way to avoid a frame of latency without "racing the beam", which AFAIK quite complicated and not compatible with most GUI frameworks. That is, if you don't want tearing.

But I may be wrong here

One frame of latency and adding a frame of latency are different things. The first is required (without tearing) the second should be avoided at all cost (athough high display refresh rates reduce the problem of "long" swapchains quite a bit).