<blockquote>
<p>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'</p>
</blockquote>
<p>Yes. This is one of the things that &quot;fullscreen exclusive&quot; 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.</p>
<p>Nowadays there is also support for &quot;borderless windowed fullscreen&quot; (see <a href="https://devblogs.microsoft.com/directx/demystifying-full-screen-optimizations/" rel="nofollow noreferrer">Fullscreen Optimizations</a> 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.)</p>
<blockquote>
<p>Does the compositor designate the 'off screen buffer' for the application</p>
</blockquote>
<p>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).</p>

CC BY-SA 4.0
2020-06-26T17:40:15.377Z
2020-06-26T17:47:51.697Z
2020-06-26T17:47:51.697Z
Nathan Reed
<p>My understanding is:</p>
<ol>
<li>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;</li>
<li>each OpenGL application has a 'default framebuffer', but can have more 'framebuffer objects';</li>
<li>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'.</li>
<li>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';</li>
<li>a display controller will read (scan?) the 'screen buffer' and convert it to a signal to be sent to the physical screen.</li>
</ol>
<p>Main question:</p>
<p>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.</p>
<p>Additionally:</p>
<ul>
<li>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 &quot;ring the compositor&quot; when its ready or</li>
<li>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)?</li>
<li>or is it a mix of the two?</li>
</ul>

CC BY-SA 4.0
2020-06-25T16:52:47.183Z
"*the application's off-screen buffer the same as its 'screen buffer'*" I think you misusued your own terminology here. You defined the "off-screen buffer" as being the front buffer, which is *not* what you render to. You render to the back buffer. So this would not be "the same location in memory that fragments had their colors originally blended onto". So what exactly are you looking for here?
Nicol Bolas
CC BY-SA 4.0
2020-06-26T08:08:14.793Z
@NicolBolas Yes, it is my understanding, too, that the back buffer is rendered to (and not the front buffer). I found on [wikipedia](https://en.wikipedia.org/wiki/Multiple_buffering) that 'Software double buffering' copies the back buffer's content to the front buffer. However, it notes compositors can copy directly from the back buffer, thus considering **it** the 'off-screen buffer' instead of the front buffer. Does it simply copy from back buffer to front buffer in full-screen mode? If so, my main question is answered with 'no' for software double buffering. But, what about 'page flipping'?
user1624691
CC BY-SA 4.0
2020-06-26T08:22:10.530Z
@NicolBolas In 'page flipping' the back buffer is rendered to, but this same location is **marked** as the front buffer when rendering is finished. Thus the front buffer is both the original location fragments were blended to and the location seen as 'off-screen buffer' by a compositor. But if the OpenGL application is in full-screen mode... could the compositor not also mark this original buffer rendered to as both the 'off-screen buffer' and the 'screen buffer'? If yes, then the answer to my original question is 'yes'.
user1624691
<opengl><buffers><frame-buffer><compositing>
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?
user1624691
# 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?

(Asked by: username_0 on 2020-06-25)

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?

**Tags:** opengl, buffers, frame-buffer, compositing

> **Comments:**
> **username_1**: "*the application's off-screen buffer the same as its 'screen buffer'*" I think you misusued your own terminology here. You defined the "off-screen buffer" as being the front buffer, which is *not* what you render to. You render to the back buffer. So this would not be "the same location in memory that fragments had their colors originally blended onto". So what exactly are you looking for here?  
> **username_0**: @username_1 Yes, it is my understanding, too, that the back buffer is rendered to (and not the front buffer). I found on [wikipedia](https://en.wikipedia.org/wiki/Multiple_buffering) that 'Software double buffering' copies the back buffer's content to the front buffer. However, it notes compositors can copy directly from the back buffer, thus considering **it** the 'off-screen buffer' instead of the front buffer. Does it simply copy from back buffer to front buffer in full-screen mode? If so, my main question is answered with 'no' for software double buffering. But, what about 'page flipping'?  
> **username_0**: @username_1 In 'page flipping' the back buffer is rendered to, but this same location is **marked** as the front buffer when rendering is finished. Thus the front buffer is both the original location fragments were blended to and the location seen as 'off-screen buffer' by a compositor. But if the OpenGL application is in full-screen mode... could the compositor not also mark this original buffer rendered to as both the 'off-screen buffer' and the 'screen buffer'? If yes, then the answer to my original question is 'yes'.  

---

## 1 answers

### Answer by username_2 on 2020-06-26. Score: 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](https://devblogs.microsoft.com/directx/demystifying-full-screen-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).


---

