Hi,
I noticed awhile ago that precise timing via VBLTimestampingMode = 1
can break down and cause a systematic error when there is a slight lag
in Flip return. Specifically, it seems that whenever a lag causes
beampos to be reported after the VBL for a single frame, it looks like
PTB overcompensates for the timing. The lags looks like this:
Pict of beampos as reported in VBLSyncTest:
http://web.mit.edu/gorlins/Public/ptb/beampos.jpg
Screen res is 1600x1200 with VBL Endline=1249
Note the two lags at the end.
Pict of VBL timestamp delta:
http://web.mit.edu/gorlins/Public/ptb/osc.jpg
The two spikes at the end correspond with the lags in the first pict,
while the spikes on the left are simply due to a dropped frame (i
increased load jitter to show this).
Zoom in on the oscillations:
http://web.mit.edu/gorlins/Public/ptb/osc_zoom.jpg
Note how they dip first then rise on the next frame.
I believe this shows that PTB is overcompensating during the
subtraction algorithm: because the oscillations dip first, it means
that the prior frame was normal, but this frame had too much time
subtracted from it during the timing calculation. Since the time is
too early, the next frame looks like it arrived too late, as seen with
the rise in the oscillation, though it actually was on time: the next
point is normal.
At first I was confused about this and thought there was nothing to be
done. It can't be attributed to additional lag in the system (such as
a longer VBL than estimated) because this would add time to the points
(causing the spike to rise first, then dip). However, with the new
Screen('GetWindowInfo', win, 1) function, I found something very
interesting:
Pict of histogram of successive beampositions, without drawing anything:
http://web.mit.edu/gorlins/Public/ptb/beampos_hist.jpg
On this set up (and I have verified this on a few other systems),
beampos is never read for certain lines! The number of missing lines
in this configuration is about 15, all of which are in the VBL, and
there are existing lines after them which do get read. Under the
assumption that these lines simply do not exist and the monitor passes
from line 1230 to 1245 in the time it normally takes to go through a
single line, timestamps from flip when it returns past the VBL would
occur 15 lines worth of time before they are expected, and PTB would
subtract that amount of time from the timestamp more than it should.
In this case, 15 * (1/60 FPS)*(1/1250 lines) = 200 us, which is
exactly the amount seen in the zoomed figure, suggesting this is what
is happening.
The nonlinearity can also be seen in this picture:
http://web.mit.edu/gorlins/Public/ptb/beampos_time.jpg
which plots the measured beampos against time. The increased slope
ending at the marker corresponds to the beamposition values which are
never measured, indicating that the monitor really does just pass
through them. The shallower slope to the left is the linear section
where the beam passes through each VBL line in the same time as it
does during drawing; the steep slope to the right is where the beampos
resets to 0. It does not seem the case that these lines are reached
but just not reported, as there would be a flat section preceeding
them (presuming a constant, false value was reported instead).
I have seen this beampos blank on several computers with old and new
graphics cards alike (nvidias and intels), all with the most recent
drivers and the latest PTB on Matlab 7.3 (the GetWindowInfo function
doesn't seem to work for me in Matlab 7.4), both on single and dual
monitor configurations, all running XP. I have not yet tested it on a
CRT however, but I have seen these types of oscillations in the past.
Could it be that missing beampos lines are common in monitors? Is
there any hope to fix this kind of nonlinearity? For instance, when
PTB runs its internal startup tasks, could it check not just for the
highest beampos measured, but for the number of unique lines, and use
this instead to calculate the right timestamps?
Thanks,
Scott
I noticed awhile ago that precise timing via VBLTimestampingMode = 1
can break down and cause a systematic error when there is a slight lag
in Flip return. Specifically, it seems that whenever a lag causes
beampos to be reported after the VBL for a single frame, it looks like
PTB overcompensates for the timing. The lags looks like this:
Pict of beampos as reported in VBLSyncTest:
http://web.mit.edu/gorlins/Public/ptb/beampos.jpg
Screen res is 1600x1200 with VBL Endline=1249
Note the two lags at the end.
Pict of VBL timestamp delta:
http://web.mit.edu/gorlins/Public/ptb/osc.jpg
The two spikes at the end correspond with the lags in the first pict,
while the spikes on the left are simply due to a dropped frame (i
increased load jitter to show this).
Zoom in on the oscillations:
http://web.mit.edu/gorlins/Public/ptb/osc_zoom.jpg
Note how they dip first then rise on the next frame.
I believe this shows that PTB is overcompensating during the
subtraction algorithm: because the oscillations dip first, it means
that the prior frame was normal, but this frame had too much time
subtracted from it during the timing calculation. Since the time is
too early, the next frame looks like it arrived too late, as seen with
the rise in the oscillation, though it actually was on time: the next
point is normal.
At first I was confused about this and thought there was nothing to be
done. It can't be attributed to additional lag in the system (such as
a longer VBL than estimated) because this would add time to the points
(causing the spike to rise first, then dip). However, with the new
Screen('GetWindowInfo', win, 1) function, I found something very
interesting:
Pict of histogram of successive beampositions, without drawing anything:
http://web.mit.edu/gorlins/Public/ptb/beampos_hist.jpg
On this set up (and I have verified this on a few other systems),
beampos is never read for certain lines! The number of missing lines
in this configuration is about 15, all of which are in the VBL, and
there are existing lines after them which do get read. Under the
assumption that these lines simply do not exist and the monitor passes
from line 1230 to 1245 in the time it normally takes to go through a
single line, timestamps from flip when it returns past the VBL would
occur 15 lines worth of time before they are expected, and PTB would
subtract that amount of time from the timestamp more than it should.
In this case, 15 * (1/60 FPS)*(1/1250 lines) = 200 us, which is
exactly the amount seen in the zoomed figure, suggesting this is what
is happening.
The nonlinearity can also be seen in this picture:
http://web.mit.edu/gorlins/Public/ptb/beampos_time.jpg
which plots the measured beampos against time. The increased slope
ending at the marker corresponds to the beamposition values which are
never measured, indicating that the monitor really does just pass
through them. The shallower slope to the left is the linear section
where the beam passes through each VBL line in the same time as it
does during drawing; the steep slope to the right is where the beampos
resets to 0. It does not seem the case that these lines are reached
but just not reported, as there would be a flat section preceeding
them (presuming a constant, false value was reported instead).
I have seen this beampos blank on several computers with old and new
graphics cards alike (nvidias and intels), all with the most recent
drivers and the latest PTB on Matlab 7.3 (the GetWindowInfo function
doesn't seem to work for me in Matlab 7.4), both on single and dual
monitor configurations, all running XP. I have not yet tested it on a
CRT however, but I have seen these types of oscillations in the past.
Could it be that missing beampos lines are common in monitors? Is
there any hope to fix this kind of nonlinearity? For instance, when
PTB runs its internal startup tasks, could it check not just for the
highest beampos measured, but for the number of unique lines, and use
this instead to calculate the right timestamps?
Thanks,
Scott