I'd like to design a simple window manager capable of compositing the outputs from multiple processes. My first idea was to only use different threads for standalone applications so I use only one context and share it between the applications' and the manager main thread, but on a second thought that doesn't sound like a good idea, since any of the threads crashing will terminate everything.
So I decided it has to actually support dedicated processes for applications but that brings me to the question, which is how exactly do I stitch outputs from different processes together and in a high-performance manner at that. Copying data from GPU to CPU to share in system memory is simply not an option. From the OpenGL parallel FAQ it became clear that using one context from multiple processes is not possibly, unless it is an indirect which results in very low performance.
So, how are existing window managers doing it? Naturally, I do not expect any low level details, just the general concept overview.
So, how are existing window managers doing it? Naturally, I do not expect any low level details, just the general concept overview.
In X11 there are the X11 extensions GLX_ARB_texture_from_pixmap and Render which allow move windows off-screen and bind the window's X11 pixmaps as textures in OpenGL. The moniker how this is implemented is called AIGLX (Accelerated Indirect GLX), which despite the name does not depend on an indirect GLX context. Indirect in this case means that everything happens on the display server.
Your compositing window manger will never talk to the other processes directly. Instead it just uses the resources and data already present in the X11 server to composit the final result.
This is different from Wayland, where the compositors do talk to the other processes directly to exchange framebuffer information. Personally I like the X11 model better, but that's just my opinion.