Hi - years ago in PTB it was recommended that we use full screen mode to improve performance. We’ve been running recently in Linux (Ubuntu 20.0.4) and doing some debugging, and our computer seems to be working well with a smaller PTB window (about a quarter of screen size). This is with a Radeon card. Just in terms of general best practices, is it the case that running in less than full screen mode incurs a performance hit?
We’re doing this not on a display seen by a user, but rather a local display that is for feedback for the operator of an experiment. Nonetheless, this display is showing continuous eye position traces and while a small performance hit might be ok we don’t want to do anything that really would cost us. There are benefits of the smaller display though, in that if we need to switch back to the OS we can see what’s happening in the Matlab console. So far we don’t see any big problems in timing from our internal metrics. Thanks for any advice.
Running non-fullscreen always incurs a performance hit on any operating system (may change if and when PTB uses Wayland instead of X11 as display system at some point in the future, and the specific Wayland display server supports use of direct scanout from secondary planes/overlay planes), but current Wayland is by far not ready for PTB’s general needs). Also on non-Linux, visual timing and timestamps are not to be trusted at all.
For Linux/X11 under certain conditions, and with various restrictions, the latest PTB adds experimental support to at least improve timing and possibly solve timestamping, see Psychtoolbox 3.0.18.5 Beta update "Experimental Taylor expansion" for details.
But yeah, if frame-accurate timing doesn’t matter for that windowed window, the perfomance hit for a not too big window should be not that high. You should use the ‘dontsync’ flag 1 or even 2 in Screen('Flip', win, dontclear, dontsync) in this case, so your script doesn’t get throttled in performance by that operator display and debug window.
-mario
Thanks! We’re running with the dontsync flag set to 2, like this:
Screen(‘Flip’,wins,0,0,2);
Matt, I also use a second non-fullscreen window (NFW) on display 0 to show the eye position, stimulus position, and some task information to the experimenter. As well as setting dontsync, another thing I do is “throttle”, i.e. not call Flip on the NFW on every frame call of the subject display, but every X frames (3 works well), just to give a bit more headroom. At 120Hz I haven’t seen any timing issues. The experimenter display doesn’t need to be updated so often…
Ian - thanks, I do exactly that. My “experimenter control” display is running on a separate computer from the subject display, and it also is updated via a timer function that gets called about 30 times a second. I could slow it down even a bit beyond that, but that works. So it’s also not called every video frame. When the system I use was under development, the 2-screen performance was not as good and I didn’t consider that as an option (split screens, one for user and one for subject). Now that is obviously much better but we’ve got things setup a different way. Thanks for the thoughts/advice!