My understanding is:
- the 'framebuffer' in OpenGL is a collection of buffers: many (due to swapping or stereo rendering) color buffers, (only one?) z-buffer and (only one?) stencil buffer;
- each OpenGL application has a 'default framebuffer', but can have more 'framebuffer objects';
- a 'compositing window manager' aka 'compositor' only cares about an application's current front color buffer of its 'default framebuffer'. The compositor calls this buffer 'off screen buffer'.
- the compositor reads all applications' 'off screen buffers' and composites them onto a single image called screen buffer' aka 'video buffer' aka 'regen(eration) buffer';
- a display controller will read (scan?) the 'screen buffer' and convert it to a signal to be sent to the physical screen.
Can it be (eg. if I run a video game full-screen) that the compositor could simply declare the application's off-screen buffer the same as its 'screen buffer' so that the same location in memory that fragments had their colors originally blended onto will actually be the location the display controller will read from? I.e. OpenGL will render to some area in either VRAM or RAM and without coincidence this same location will be read by the display controller even after any sort of compositor stage.
- Does the compositor designate the 'off screen buffer' for the application (or multiple locations for double/triple buffering or stereo) and it's up to the application to fill that area in memory and "ring the compositor" when its ready or
- does the application create the buffer and the compositor is only told where to read from (eg. the app's OpenGL draws to a back buffer, designates it as the front and tells the compositor to read it)?
- or is it a mix of the two?