<p>It entirely depends what hardware and OS you're on. It's up to the integration between the windowing system and GL. In the simple case where one application is rendering full-screen directly, the framebuffer is in memory that's accessible by both the GPU and the display controller. After the GPU is finished, and when the display controller gets to a vsync (the time to start drawing a new frame to the screen), the display controller just reads out the framebuffer.</p>

<p>In a compositing system like modern MS Windows or Android, your app's framebuffer is not used by the display controller directly. After you finish drawing your frame, the compositor runs. On the GPU, it reads in your framebuffer, puts it in the right place on the desktop, and writes the composited desktop into the real framebuffer. The display controller then reads out the desktop framebuffer. There's also an optimization possible using <a href="https://computergraphics.stackexchange.com/q/5271/20410">overlays</a>, which we have another question about.</p>

<p>Copying completed frames into CPU memory is to be avoided. If you had to do this every frame, your application probably couldn't run at a reasonable frame-rate. Even reading back a single pixel (with <code>glReadPixels</code>) is a big slow-down, because the CPU has to wait for the GPU to finish, and they have to invalidate the cache of any shared memory. Reading back a million pixels is extra slow on desktop because the CPU and GPU have separate memory and the path between them is relatively slow. It's very rare that it should be necessary: mainly it's needed for screenshots, or for debugging.</p>

CC BY-SA 3.0
2017-11-14T04:05:09.740Z
I noticed while learning basic Direct3D recently, you generally specify a single framebuffer when creating your swapchain. I'm guessing this simply gets blitted to the compositor when 'swapping' buffers? How about when switching to fullscreen mode, does a separate front buffer get created for you in that case?
russ
CC BY-SA 3.0
2017-11-14T10:47:03.277Z
I don't know the specifics about Direct3D, but both those guesses are plausible. Typically the application framebuffer looks like a texture to the compositor, which it'll put on a quad of the appropriate size and position. I have no idea what fullscreen on MS Windows does: it may be something more complicated.
Dan Hulme
CC BY-SA 3.0
2017-11-14T10:48:05.200Z
If you ask a new question specifically about D3D fullscreen, it's more likely to be seen by someone who knows.
Dan Hulme
CC BY-SA 3.0
2017-11-14T12:09:42.933Z
OK, was just curious about how this worked in general, didn't want to open a duplicate-ish question. I don't think it's API-specific anyway, since OpenGL under Windows uses the same DXGI backend as D3D does.
russ
CC BY-SA 3.0
2017-11-13T09:42:58.247Z
2017-11-13T09:42:58.247Z
Dan Hulme
<p>I'm wondering what happens with the framebuffer between the time that the fragment shader is done, and the time when it appears on my screen. </p>

<p>Is my understanding correct if I assume that the framebuffer is in memory on the GPU, which is then copied back to the CPU side after glDrawX is completed, and then fit to a window somewhere on the screen, and then sent through my HDMI cable (via the GPU again!) to my monitor?</p>

<frame-buffer><hardware>
What happens with the framebuffer after the fragment shader is done?
Supernormal
# What happens with the framebuffer after the fragment shader is done?

(Asked by: username_0 on 2017-11-13)

I'm wondering what happens with the framebuffer between the time that the fragment shader is done, and the time when it appears on my screen.

Is my understanding correct if I assume that the framebuffer is in memory on the GPU, which is then copied back to the CPU side after glDrawX is completed, and then fit to a window somewhere on the screen, and then sent through my HDMI cable (via the GPU again!) to my monitor?

**Tags:** frame-buffer, hardware


---

## 1 answers

### Answer by username_1 on 2017-11-13. Score: 4 | Accepted answer

It entirely depends what hardware and OS you're on. It's up to the integration between the windowing system and GL. In the simple case where one application is rendering full-screen directly, the framebuffer is in memory that's accessible by both the GPU and the display controller. After the GPU is finished, and when the display controller gets to a vsync (the time to start drawing a new frame to the screen), the display controller just reads out the framebuffer.

In a compositing system like modern MS Windows or Android, your app's framebuffer is not used by the display controller directly. After you finish drawing your frame, the compositor runs. On the GPU, it reads in your framebuffer, puts it in the right place on the desktop, and writes the composited desktop into the real framebuffer. The display controller then reads out the desktop framebuffer. There's also an optimization possible using [overlays](https://computergraphics.stackexchange.com/q/5271/20410), which we have another question about.

Copying completed frames into CPU memory is to be avoided. If you had to do this every frame, your application probably couldn't run at a reasonable frame-rate. Even reading back a single pixel (with `glReadPixels`) is a big slow-down, because the CPU has to wait for the GPU to finish, and they have to invalidate the cache of any shared memory. Reading back a million pixels is extra slow on desktop because the CPU and GPU have separate memory and the path between them is relatively slow. It's very rare that it should be necessary: mainly it's needed for screenshots, or for debugging.

> **Comments:**
> **username_2**: I noticed while learning basic Direct3D recently, you generally specify a single framebuffer when creating your swapchain. I'm guessing this simply gets blitted to the compositor when 'swapping' buffers? How about when switching to fullscreen mode, does a separate front buffer get created for you in that case?  
> **username_1**: I don't know the specifics about Direct3D, but both those guesses are plausible. Typically the application framebuffer looks like a texture to the compositor, which it'll put on a quad of the appropriate size and position. I have no idea what fullscreen on MS Windows does: it may be something more complicated.  
> **username_1**: If you ask a new question specifically about D3D fullscreen, it's more likely to be seen by someone who knows.  
> **username_2**: OK, was just curious about how this worked in general, didn't want to open a duplicate-ish question. I don't think it's API-specific anyway, since OpenGL under Windows uses the same DXGI backend as D3D does.  

---

