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?
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.
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.
1 Like
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.