Schedule an asynchronous flip of front and back display surfaces for given
onscreen window. "windowPtr" is the id of the onscreen window whose content
should be shown at flip time. "when" is the requested stimulus onset time, a
value of zero or no argument asks for flip at next possible vertical retrace.
For the meaning and explanation of all other parameters, see the help for
'
Screen Flip?'.
This command doesn't return anything, you'll need to use the finalizer commands
mentioned below to collect information about the final result and timing of the
flip operation.
The difference between
Screen('
AsyncFlipBegin',...); and the more commonly used
Screen('
Flip', ...); is that
Screen('
Flip') operates synchronously: Execution of
your code is paused until the flip operation has finished, ie. at least until
the requested onset deadline 'when' has passed.
Screen('
AsyncFlipBegin') will prepare everything for a flip at the requested
time 'when' - or at next vertical retrace if 'when' is omitted - but then
immediately return control to your code. Your code can continue to execute and
do other things, e.g., schedule flips for other onscreen windows, perform
keyboard or mouse queries, etc.
You can check the progress state of asynchronous flips or wait for them to
finish and collect timing information for the finalized flip by use of the
commands
Screen('
AsyncFlipCheckEnd') and
Screen('
AsyncFlipEnd');
In general you should avoid using asynchronous flips and instead use
conventional '
Flip' unless you have a good reason to do otherwise, because async
flips come with a couple of strings attached:
- You are restricted in what you can do with
Screen() or
OpenGL while async
flips are in progress: You can not do anything with textures or offscreen
windows while any onscreen window is in async flip state. You can only
access onscreen windows which are not participating in an async flip
operation. Even the restricted set of allowed
Screen/
OpenGL commands should
be avoided if possible, because some graphics hardware and drivers may not be
able to handle such concurrent graphics operations without degraded stimulus
onset timing accuracy, ie. you may experience more missed stimulus deadlines
and timing glitches -- or inconsistent behaviour accross different computers
and graphics cards or operating system releases. In the end it allows you to
do non-
Screen related things like sound, I/O, keyboard checks...
- Parallel processing of flips puts additional burden and load onto your CPU,
GPU and operating system, so it incurs additional overhead and may degrade
absolute drawing performance and cause more timing issues and glitches if
your system is not reliably able to handle the concurrent load.
- Code with async flips - as any piece of parallel code - is harder to
get right and more challenging to debug for you.
- Using a non-zero "multiflip" argument is not allowed.
- Asynchronous updates of gamma tables may not work reliably.
- Use of the '
UserspaceBufferDrawingPrepare' hook-chain of the imaging
pipeline is not allowed.
Our general stance is that most code can be written efficiently without need for
async flips, so this feature is here for the few cases where this is not the
case and the benefits outweight the costs.