<p>You're confusing the <em>screen</em> (the physical display) with the <em>framebuffer</em> (the memory which gets read out by the <em>display controller</em>). The framebuffer might get cleared at the start of each frame period, but that doesn't change the display. The order of events is as follows:</p>

<ul>
<li>At the start of a new frame, <code>glClear</code> or equivalent sets the framebuffer to the clear colour.</li>
<li><code>glDraw</code> or equivalent calls draw more stuff on top of the clear colour.</li>
<li><code>eglSwapBuffers</code> or equivalent queues the finished frame to be drawn on the display.</li>
<li>When the display is ready, <a href="https://computergraphics.stackexchange.com/a/5863/2041">this process</a> is followed. It reads out the contents of the framebuffer and shows them on the physical screen.</li>
</ul>

<p>The framebuffer that's being drawn into is never shown on the screen; only when it's finished can it be shown. Double- or triple-buffering gives you multiple copies of the framebuffer, so the application can be using one while the display is using the other. It's nothing to do with your eyes or brain.</p>

<hr>

<p>It's actually a lot more complicated than this, because most GL implementations today are not immediate-mode, so none of the real work happens when you call the functions named above. In fact, clearing the buffer might not even happen at all: if every pixel is drawn to anyway, there's no need to. Back when clearing the framebuffer took significant time, games would go faster by not calling <code>glClear</code>. Today it's more important to call <code>glClear</code> because it lets the implementation know when the start of the new frame is, but it will probably do something smarter than just writing to every pixel.</p>

CC BY-SA 3.0
2017-12-14T15:34:11.940Z
Thanks for the enlightenment! Never thought about it this way.
nightrobin
CC BY-SA 3.0
2017-12-12T15:07:37.507Z
2017-12-12T15:07:37.507Z
Dan Hulme
<p>I am told that in computer graphics, the screen refreshes in number of times(in this scenario let say that it <strong>renders</strong> <strong>60</strong> times per second). The screen is cleared and drawn to 60 times per second.</p>

<p>My question is how can I see the <strong>Image</strong> being shown 60 times per second yet I cannot see the <strong>Clear Color</strong> which is also being displayed 60 times per second too?
Or does this have to do with how our eyes see or how our brain interprets things we see?</p>

<rendering><image>
Why isn't the clear color visible on the screen between frames?
nightrobin
# Why isn't the clear color visible on the screen between frames?

(Asked by: username_0 on 2017-12-12)

I am told that in computer graphics, the screen refreshes in number of times(in this scenario let say that it **renders** **60** times per second). The screen is cleared and drawn to 60 times per second.

My question is how can I see the **Image** being shown 60 times per second yet I cannot see the **Clear Color** which is also being displayed 60 times per second too?
Or does this have to do with how our eyes see or how our brain interprets things we see?

**Tags:** rendering, image


---

## 1 answers

### Answer by username_1 on 2017-12-12. Score: 7 | Accepted answer

You're confusing the *screen* (the physical display) with the *framebuffer* (the memory which gets read out by the *display controller*). The framebuffer might get cleared at the start of each frame period, but that doesn't change the display. The order of events is as follows:

* At the start of a new frame, `glClear` or equivalent sets the framebuffer to the clear colour.
* `glDraw` or equivalent calls draw more stuff on top of the clear colour.
* `eglSwapBuffers` or equivalent queues the finished frame to be drawn on the display.
* When the display is ready, [this process](https://computergraphics.stackexchange.com/a/5863/2041) is followed. It reads out the contents of the framebuffer and shows them on the physical screen.

The framebuffer that's being drawn into is never shown on the screen; only when it's finished can it be shown. Double- or triple-buffering gives you multiple copies of the framebuffer, so the application can be using one while the display is using the other. It's nothing to do with your eyes or brain.

---

It's actually a lot more complicated than this, because most GL implementations today are not immediate-mode, so none of the real work happens when you call the functions named above. In fact, clearing the buffer might not even happen at all: if every pixel is drawn to anyway, there's no need to. Back when clearing the framebuffer took significant time, games would go faster by not calling `glClear`. Today it's more important to call `glClear` because it lets the implementation know when the start of the new frame is, but it will probably do something smarter than just writing to every pixel.

> **Comments:**
> **username_0**: Thanks for the enlightenment! Never thought about it this way.  

---

