| Reference | Downloads | Github

Cannot disable window


i have created a stimulus, and would now like to scale it, but generating multiple samples (>100,000).
i have written a shell script that scales well on local machine, and does what i expect it to do,
but would now like to submit the job on a cluster, which would simply generate everything for me.

i was wondering if there is a way to disable the display screen completely. On setting allowGUI=False in psychopy.visual.Window, i can get rid of the buttons and stuff; but was wondering if there is anyway of turning the screen off completely (specially for no-graphic clusters).
By turning off the screen, i imply that the stimulus should not be displayed on the screen, but rather just stored on disk.
(i have getMovieFrame and saveMovieFrame in my code to do that).

Thank you.

Maybe I misunderstood what you want.
But if you do not need your stimuli to be drawn on the screen, then just do not do it:


But in that case, would i still be able to use getMovieFrame() to get the frames?
If i do not draw, then it would not generate anything at all, right?

@Vitali is correct, you don’t need to call win.flip(). In your call to win.getMovieFrame(), you should just be able to specify buffer = 'back' (because you aren’t flipping the content to the front buffer where it normally gathers the image from).

You certainly still need to .draw() the stimuli, to get them into the back buffer at all. It’s just the win.flip() that is optional in this case.

You will also need to manually clear the back buffer for your next cycle of drawing, as that won’t happen for you automatically without the win.flip().

1 Like

Thanks @Michael
i did follow what you told. i skipped win.flip(), and used buffer="back",
followed by win.clearBuffer().
That does produce what i need, but it still generates an instance of screen, and i believe it still requires a display to do that.
i am trying to run it on a completely headless server, without any display or graphic component.
Can you suggest a way of skipping the display altogether?


I honestly don’t whether or not the Window class needs a physical display in order to be successfully instantiated – sounds like a question for @jon

Skipping the display altogether is probably technically possible but not important (having the window exist won’t be impacting your performance in any meaningful way). It doesn’t solve the main goals of PsychoPy (running experiments efficiently) so I don’t think the dev team will be working on it anytime soon, so it probably means you needing to learn enough OpenGL to do the work manually but I wouldn’t think it’s worth it for the performance gains you’ll see

Thanks @jon
i am not looking for specific optimizations in this case.
All that i am trying to do is run my script on a headless
server, so that i can generate my stimuli in large numbers.
Given the absence of a screen, it is important that i should
be able to turn the display off completely, and
psychopy.visual.Window should be able to run with a fake/
virtual screen, with the need of a physical display.

Not easy to do since OpenGL frameworks typically require a window to be associated with a context.


GLFW doesn’t support creating contexts without an associated window. However, contexts with hidden windows can be created with the GLFW_VISIBLE window hint.

It is possible to get the GLFW backend to create a hidden window and render off-screen, but it would require special handling in the window class to deal with it since PsychoPy assumes there is a back buffer to draw to.

Thanks @mdc.
i think this is on the lines of what i am looking for,
but i still do not understand how to do it.
Also, my presumption was that the
psychopy.visual.Window relies on pyglet by default,
and not GLFW. Am i missing something here?

In a nutshell, what, if possible, is a good way of doing
off-screen rendering of psychopy windows?
Thank you.

You’ll probably need a window manager to even do off-screen rendering. So I’m not sure headless rendering is possible at the moment.

Thanks @mdc
Is there any possible work around, that can be done with minimal changes,
given the clusters are centrally managed, and not much can be done there?