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