Best use of offscreen windows and asynchronous flips to draw quickly

Programming Help
,
1

I’m writing a time perception experiment requiring precisely timed screen flips. I need to show an image on-screen, then after a very brief delay, show a second image.

At the moment, this is how I do it:

  1. Draw first image to window’s backbuffer, then issue the ‘DrawingFinished’ hint
  2. Schedule first flip using Screen(‘Flip’,window,time)
  3. Draw second image to window’s backbuffer, then issue ‘DrawingFinished’ hint
  4. Schedule second flip using Screen(‘Flip’,window,time)

I’m only drawing very simple shapes to the screen so in reality it probably doesn’t matter, but nevertheless I wonder if the drawing operations taking place at step #3 have the potential to cause missed flips. Ideally, I would do both drawing operations before step #2 to minimise CPU processing between the two flips.

Here are two ways I thought I could do this, but which turned out not to work:

  1. Using asynchronous flips: I had hoped that by scheduling an asynchronous flip I might be able to then draw the second image to a clean backbuffer before the first flip actually occurs. However this doesn’t work as it’s not possible to perform draw operations while a flip is scheduled, and the backbuffer isn’t cleared until the flip occurs anyway.
  2. Opening a second offscreen window: I had hoped that I could use Screen(‘OpenOffscreenWindow’) to open a second window, draw my second image to that window, and then flip one window after the other in quick succession. However that’s not possible either as PTB can only flip onscreen windows. So in that regard I seem to have misunderstood the purpose of offscreen windows.

Is there some smart way to line up more than one image to be flipped in quick succession, or am I overthinking this? My two ‘images’ are actually nothing more than simple circles, so it’s unlikely to cause much of a slowdown. I’m aware of the concept of pre-loading complex images as Textures, but as I understand it, this would be unnecessary given the simplicity of the shapes I’m drawing?

Note: I’m not raising this issue because PTB is reporting missed flips; I already use a timing-precision optimised low-latency Linux system. I’m simply trying to improve my coding practise to minimise the likelihood of missed flips occurring in the first place.

2

Hi Matt,

It sounds very unnecessary. But, you were almost there with the offscreen window approach. Instead of flipping an offscreen window, you draw that as a texture in the backbuffer and then issue a regular flip. That way you could predraw everything to an offscreen window, as complicated as you wish, and then to show it all is just a single drawtexture–will be fast enough for sure.

Also, drawingfinished followed by a flip is superfluous, you can just flip

Cheers,
Dee

3

It is very unnecessary. And the offscreen window approach would be one way to prerender and show very demanding stimuli if everything else fails.

Your approach 1 with async flips also works, iff you enable the imaging pipeline a la…

PsychImaging('PrepareConfiguration');
PsychImaging('AddTask', 'General', 'UseVirtualFramebuffer');
w = PsychImaging('OpenWindow', screenid, 0);

→ The use of the virtual framebuffer gives you that 3rd buffer that you can draw into the next stimulus image while Asyncflip keeps the regular framebuffer busy.

AsyncFlipTest.m demonstrates all kinds of such async flips and approach 1.

If you don’t need your code to run on non-Linux system and use a graphics card with the open-source drivers (== not NVidia with proprietary driver), then PerceptualVBLSyncTestFlipInfo2.m shows how one can draw and flip frames as fast as possible, not waiting for flips to complete, and collect all stimulus onset timestamps later, e.g., at the end of a trial. This allows to pre-queue potentially multiple frames depending on gpu.

But in practice almost certainly none of this matters for your circles, and simple is simpler.

-mario