Can the framebuffer in OpenGL jargon or its color buffer end up being the one and the same memory location as the one scanned by a display controller?

Question

My understanding is:

1. 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;
2. each OpenGL application has a 'default framebuffer', but can have more 'framebuffer objects';
3. 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'.
4. 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';
5. a display controller will read (scan?) the 'screen buffer' and convert it to a signal to be sent to the physical screen.

Main question:

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.

Additionally:

• 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?

Answer 1

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'

Yes. This is one of the things that "fullscreen exclusive" mode would do for you: it enables the application's swap buffers (front/back default framebuffers) to be directly scanned out by the GPU's display engine, without needing to go through a compositor first, saving a little bit of performance.

Nowadays there is also support for "borderless windowed fullscreen" (see Fullscreen Optimizations for Windows 10 for instance, though I expect other OSes have similar functionality). This is a mode where you still go through the compositor, but the compositor has a shortcut method when it detects that your app is covering the full screen with no other windows rendering on top of it. In that case it can skip the compositing steps and scan out directly from your swap buffers, while retaining the ability to seamlessly switch back to compositing mode if another window should pop up (such as an overlay, or if you Alt+Tab away from the game, etc.)

Does the compositor designate the 'off screen buffer' for the application

Also yes. When you set up an OpenGL context (or any other graphics API context) your app will request the number and format of swap buffers it wants (subject to the choices offered by the OS/driver); then the OS/driver will give you the buffers, and you render into them. You can create your own framebuffers as well, such as depth/stencil buffers or other offscreen buffers for whatever purpose, but ultimately your app will need to put the image you want to show up on the screen into the provided swap buffers. The buffers will be set up so the compositor can also access them. When you do a glSwapBuffers call, you're informing the OS/compositor that you finished a new frame and asking it to please show that on the screen (either by scanning it out directly or by including it in the next compositor frame).