3 ms·

Compositors under X11 were about adding drop shadows & translucency to windows, and occasionally inducing motion sickness. A Wayland compositor should be though

Compositors under X11 were about adding drop shadows & translucency to windows, and occasionally inducing motion sickness. A Wayland compositor should be thought of as a display server, like Xorg (plus the WM, minus the legacy cruft). You can still write a pretty compact one with wlroots though. Which is my point. A project like wlroots should have been in the spotlight the same way Xorg was, so that new compositors (or existing X11 WMs) could adopt it easily, and both users and developers could benefit from an emerging-but-stable ecosystem. Instead it took like a decade to standardise and implement screen capture.

ChocolateGod 2y ago
> Compositors under X11 were about adding drop shadows & translucency to windows, and occasionally inducing motion sickness. Because compositors had graphic pipelines and could add those with OpenGL shaders. But, there's still much more to a compositor, namely they actually composite the windows/screen, rendering things into GL textures and intercepting the rendering pipeline in X, ensuring everything is synced to avoid tearing etc. This is their main purpose. Wayland is just an API that lets clients talk to the compositor direct rather than having to go through the X server.
- rollcat 2y ago
  OK so I see that I didn't appreciate the complexity here. So even a "trivial" compositor like xcompmgr, that runs alongside a WM, has to do all of this dance? The WM still has the authority to tell X, "draw this window here", but X lets xcompmgr take the wheel? (I can tell from here why X was already becoming more of a drag.)
  - ChocolateGod 2y ago
    Yeh and because compositors had to pull from X and push again, it added additional latency and work (having to copy around buffers). Wayland (as an API) was designed to solve, which is why in theory it's supposed to have better performance, latency and power efficiency, although it hasn't worked out great in all cases.

ChocolateGod 2y ago

> Compositors under X11 were about adding drop shadows & translucency to windows, and occasionally inducing motion sickness. Because compositors had graphic pipelines and could add those with OpenGL shaders. But, there's still much more to a compositor, namely they actually composite the windows/screen, rendering things into GL textures and intercepting the rendering pipeline in X, ensuring everything is synced to avoid tearing etc. This is their main purpose. Wayland is just an API that lets clients talk to the compositor direct rather than having to go through the X server.

rollcat 2y ago
OK so I see that I didn't appreciate the complexity here. So even a "trivial" compositor like xcompmgr, that runs alongside a WM, has to do all of this dance? The WM still has the authority to tell X, "draw this window here", but X lets xcompmgr take the wheel? (I can tell from here why X was already becoming more of a drag.)
- ChocolateGod 2y ago
  Yeh and because compositors had to pull from X and push again, it added additional latency and work (having to copy around buffers). Wayland (as an API) was designed to solve, which is why in theory it's supposed to have better performance, latency and power efficiency, although it hasn't worked out great in all cases.