When should I schedule screen flips?

Programming Help
1

In the past, I’ve always set the [when] argument of a Screen('Flip') or Screen('AsyncFlipBegin') command to be exactly half a frame duration before I want the flip to actually occur. The logic, as I understood it, was that by scheduling the flip half a frame early, you minimise the chance that the system misses the flip.

More recently, I’ve seen code which either (a) schedules the flip half a frame after the desired time, or (b) just schedules the flip for the exact time required.

I wonder whether I’m using an outdated method (perhaps PTB deals with the half-frame offset automatically these days?), or if I might just have this completely backwards, and there is some logic to scheduling after the required time?

Just want to check I’m doing things correctly…

2

Hmm, we defer to Mario here, but it seems to me that after is crazy (how could it possible appear on time if you ask for later?) and asking for the exact time is asking for trouble (missed deadlines). Perhaps when using a VRR screen and PTB properly set up for that on a well working system the precise when makes sense, otherwise no. For normal cases, with normal screens, doing half a flip before is the right way, as the flip will occur at the next possible moment, and you are giving it enough time to not miss that deadline

1 Like
3

Yes, setting “when” to half a frame earlier should work best.

I would also suggest you record the “real” onset time returned by Screen('Flip'), rather than relying on the pre-calculated onset time, just in case delay happens due to unexpected reason. For experiment with high precision requirement, such as EEG recording, a trigger signal to the recording system immediately after Screen('Flip') is used rather than relying on the onset timestamp at the stimulus computer.

If the display updates for each frame, we won’t bother to provide the “when” argument. We just make sure the computation time between frames won’t exceed a frame.

4

As Diederick says, and explained in our intro pdf.

The rule for Screen('Flip', window, tWhen) was and is “flip as soon as possible, but no earlier than tWhen”, ie. at the smallest t with t >= tWhen.

That rule won’t change, because we don’t break backwards compatibility without very good reasons. If that doesn’t work, then it is either a PTB bug (unlikely, given the amount of testing wrt. timing), or an operating-system / graphics driver bug or system misconfiguration which needs to be fixed.

Half a frame early is the recommended method for all standard fixed refresh rate displays, as it maximizes headroom for dealing with timing noise. This is not really needed on Linux with open-source drivers, where you could go very close to the true frame boundary, but it is helpful for more primitive operating systems like macOS or Windows, or the NVidia proprietary driver on Linux.

The exception is fine-grained timing mode on supported OS + gpu + display combos, ie. atm. only Linux + AMD + FreeSync/DP-adaptive sync monitor for reasonable quality, or Linux + Nvidia for poor quality. There you must specify the true desired onset time, and the system will try to get stimulus onset as close as possible to the desired tWhen. But this mode is not on by default, and our VRRTest shows how to use it.

@xiangrui I’m not sure if i misundertstand what you mean, but to clarify: The onset time reported by Screen('Flip') is not a prediction, but a measurement. Either done and reported by the operating system (on Linux with open-source drivers), or calculated by PTB from measurement of hardware state (Linux + NVidia proprietary, Windows in one of the working configurations, or macOS with properly working PsychtoolboxKernelDriver on AMD or NVidia, or on Intel if the feature is explicitely forced on by the user). The cases in which our timestamping would fail are the same ones in which waiting after Screen('Flip') then sending a trigger would fail, which are the same ones where PTB will usually detect and report timing trouble. In terms of precision, a trigger after Flip will always be a bit less accurate than what the Flip timestamp reports, due to scheduling delays etc.