matlab & PTB 学习笔记03——精确时间控制

一、vbl = Screen('Flip', windowPtr);

vbl：vertical blank（垂直空白，CRT显示器电子束扫完最后一行最右边的像素点时，会跳回到第一行最左边的像素点重新开始扫描。这个跳跃的时间段），标记了 " Flip " 动作完成的时间点。

二、ifi = Screen('GetFlipInterval', w);

monitor refresh interval (aka IFI)

同：ifi = 1.0 / Screen('NominalFramerate',screenNum) ;（好像这个更准一点，0.0167s）

二、vbl = Screen('Flip', windowPtr, vbl + 【下一次翻转间隔/秒】 - 0.5 *ifi ); 

 “- 0.5 *ifi” 消除滞后误差

so we are asking to flip half an ifi before the next refresh. Why not just ask to flip on the next refresh, i.e. vbl + ifi? Because that sum is a floating-point calculation and may contain small rounding errors. Screen('Flip') can only swap the screen buffers on the next monitor refresh, so what happens if the error in that sum slightly overshoots? Then you've just asked for a flip time slightly beyond the monitor refresh you actually wanted, and PTB has to wait almost an entire ifi to actually flip**.

So we ask for a flip time some amount (less than ifi) before the desired monitor refresh - ifi/2 is reasonable. We're really saying "do the next flip ASAP after vbl+ifi/2", knowing both that Screen('Flip') can't actually do it prior to the refresh, and safe in the knowledge that we have ifi/2 leeway to absorb minor inaccuracies in the timing calculation.

The arithmetic of waitframes is left as an exercise for the reader.

*assuming PTB is set up correctly to play nice with your hardware - pay attention to those warning messages!

**Even worse, this might not show up in PTB's errors e.g. the dropped frame count, because PTB has achieved what you asked it: flipped the buffers on the next monitor refresh from your specified time. In that case the only way you'd know your experiment was lagging and presenting mis-timed stimuli would be if you happened to spot it during runtime!

【matlab - Explaning a line in code from PsychToolBox tutorial - Stack Overflow】