# Different behaviour of 'dontclear' in screen flips on Linux?

**URL:** <https://psychtoolbox.discourse.group/t/different-behaviour-of-dontclear-in-screen-flips-on-linux/4571>\
**Category:** Bugs & Features\
**Tags:** windows, linux\
**Created:** [August 11, 2022, 1:49pm UTC](https://psychtoolbox.discourse.group/t/different-behaviour-of-dontclear-in-screen-flips-on-linux/4571 "2022-08-11T13:49:15Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![matt\_j\_dunn](https://yyz2.discourse-cdn.com/free1/user_avatar/psychtoolbox.discourse.group/matt_j_dunn/32/376_2.png) [@matt\_j\_dunn](https://psychtoolbox.discourse.group/u/matt_j_dunn)\
**Post date:** [August 11, 2022, 1:49pm UTC](https://psychtoolbox.discourse.group/t/different-behaviour-of-dontclear-in-screen-flips-on-linux/4571/1 "2022-08-11T13:49:15Z")

</div>

Not sure if this is a bug, or a known discrepancy in how Linux vs Mac/Windows handles the ‘dontclear’ flag. The `Screen('Flip',...)` command contains an argument **dontclear** which, when set to **2** ought not to clear the backbuffer when the screen is flipped, allowing for incremental drawing of stimuli on-screen. This works fine on my Mac, but in the lab (low-latency Ubuntu Linux) any Screen(‘Flip’)s with the dontclear flag set to 2 either _do_ clear the backbuffer, or simply fail to flip at all (as if the Flip command were not present at all).

Is there something I am supposed to know about using the **dontclear** flag in Linux versus on a Mac?

---

<div class="post-metadata">

**Author:** ![mariokleiner](https://avatars.discourse-cdn.com/v4/letter/m/13edae/32.png) [@mariokleiner](https://psychtoolbox.discourse.group/u/mariokleiner)\
**Post date:** [August 11, 2022, 5:50pm UTC](https://psychtoolbox.discourse.group/t/different-behaviour-of-dontclear-in-screen-flips-on-linux/4571/2 "2022-08-11T17:50:06Z")

</div>

From the help of `Screen Flip?`: ““dontclear”  
If set to 1, flip will not clear the framebuffer after Flip - this allows  
incremental drawing of stimuli. The default is zero, which will clear the  
framebuffer to background color after each flip. A value of 2 will prevent Flip  
from doing anything to the framebuffer after flip. This leaves the job of  
setting up the buffer to you - the framebuffer is in an undefined state after  
flip.”

→ dontclear = 1 prevents clearing → If you use that, it usually makes sense to also use the imaging pipeline with at least the ‘UseVirtualFramebuffer’ task, because without it, overhead is higher on most systems, because the way dontclear otherwise works is by making a backup copy of the backbuffer before flip, then restoring the new post-flip backbuffer from the backup, ie. two full extra framebuffer copies. With imaging pipeline you always need at least one framebuffer copy from the virtual framebuffer to the system backbuffer, potentially applying post-processing, but it really doesn’t clear that virtual framebuffer, so you save one extra copy.  
 → dontclear = 2 “the framebuffer is in an **undefined state** after flip” → Saves a bit of processing time, but results are highly dependent on OS, OS version, gpu vendor/model/driver version etc. I think this setting is mostly useful for my development and testing, not so much for end-user scripts. That it would fail to flip completely seems unlikely though.

---

<div class="post-metadata">

**Author:** ![mariokleiner](https://avatars.discourse-cdn.com/v4/letter/m/13edae/32.png) [@mariokleiner](https://psychtoolbox.discourse.group/u/mariokleiner)\
**Post date:** [August 12, 2022, 10:51pm UTC](https://psychtoolbox.discourse.group/t/different-behaviour-of-dontclear-in-screen-flips-on-linux/4571/3 "2022-08-12T22:51:35Z")

</div>

Btw., because i wonder if you fooled yourself if you used dontclear=2 for incremental drawing: Something a dontclear = 2 will probably never do is enable simple incremental drawing. On a double-buffered system, which Windows or macOS would likely be, it would give you the frame that was on-screen before the flip, ie. When you try to incrementally draw frame n+1, you’d not draw it on top of frame n as intended, but on top of frame n-1. Unless a desktop compositor is active and you might get frame n-2 or frame n as basis, plus totally broken visual stimulation timing. On Linux depending on specific setup and what the system thinks is optimal for performance at any given point in time (may change dynamically), you could get anything from n-1 to n-4, to black, to something totally undefined or unrelated.

What you basically never get with dontclear = 2 is something suitable and safe for incremental drawing. That’s what dontclear=1 specifically is for.

---

<div class="post-metadata">

**Author:** ![matt\_j\_dunn](https://yyz2.discourse-cdn.com/free1/user_avatar/psychtoolbox.discourse.group/matt_j_dunn/32/376_2.png) [@matt\_j\_dunn](https://psychtoolbox.discourse.group/u/matt_j_dunn)\
**Post date:** [August 16, 2022, 10:01pm UTC](https://psychtoolbox.discourse.group/t/different-behaviour-of-dontclear-in-screen-flips-on-linux/4571/4 "2022-08-16T22:01:29Z")

</div>

Thanks for this Mario. For some reason I had it in my head that ‘2’ was the appropriate value to prevent clearing. I’ve changed this now to 1 and we will check again in the lab.

All the best.
