| Reference | Downloads | Github

Why do I need to flip the window twice to see by buffer?


I have noticed that my changes are only drawn to the screen upon the second flip. See the following snippet. I would expect the screen to be white for 5 seconds … and then switch to black for 4 seconds.

"""Test psychopy double win flip."""
from psychopy import visual, core

win = visual.Window(size=[256, 144],

if __name__ == '__main__':
    win.color = [1, 1, 1]  # make window white
    # win.flip()
    win.color = [-1, -1, -1]  # make window black
    # win.flip()
    win.flip()  # this should do nothing because we did not draw since the last flip

What I see instead is a gray screen for 5 seconds, and then a white screen for 1 second … and then a black screen for 3 seconds. Only if I uncomment the secondary .flip() commands do I get what I expect.

I take this as evidence that my changes only become visible upon the second flip.

Has this issue been seen before? Is it perhaps related to pygame? Unfortunately, I have to use pygame, because I get a set of issues otherwise (see: Gamma problem in v1.90.2)


Check your graphics card settings to see if you have triple buffering or similar enabled?


No, this is actually a thing to do with the window. And OpenGL. Setting a window color alters the color that the window will start with on the next flip, but that will only become visible on the flip after. A stimulus can change it’s color instantly though, so you should just create a Rect the size of the window (size=2, units=‘norm’) and that change the color of that


You might be able to force changing the background color by calling win.clearBuffer() immediately after setting the color.


Thanks for your responses, @jon’s and @mdc’s solutions both worked.

did I miss the note that the background color window is actually only updated after the second flip? If there is no such note, it might be worth adding it (tell me where and I can do it :slight_smile: )


Yes, it is explicit in the docs. The issue is that very few people sit down and read the docs!

But @mdc’s suggestion makes me wonder if we should implement clearBuffer() automatically after setting the color of a window though. The surprising artefact there might be that people weren’t expecting their already-drawn stimuli to be wiped off the screen (which it would do) but at least that would be a “catastrophic” failure so people would notice it. The current mistake crops up rarely, but could have an impact because it’s somewhat subtle (many people wound’t notice a 1-frame delay in a color change even though it might matter). I had previously wondered about simply removing the option to change win color for this reason.


I agree … better to have a catastrophic failure that makes you read the docs and fix it, than a quiet failure that you never notice.


Most other settings seem to take effect immediately, so people may assume the same for ‘color’. However, it’s pretty clear in the documentation this is only applied the next time the window is cleared. It could be renamed to ‘clearColor’ to hint people that this works differently than ‘color’ for stimuli and that a read through the docs is warranted.