flicker and double buffering

[ftornay at ugr.es]

The issues brought about by Georg Odenthal are very interesting and I would
greatly appreciate it, Georg, if you could send me your programs.

However, the flickering problem can be solved just by copying large portions of
the screen from a offscreen canvas object, no matter how long the copying
process takes. For instance

'*** Code in the script user tab
'declare variable for offscreen buffer
dim offscreen as canvas

'*** Inline object at the beginning of the experiment
'create offscreen canvas
set offscreen = display.createcanvas

'and, for instance, load a file, it would also be possible to combine different
'images by copying several canvas objects to the offscreen object
offscreen.loadimage "bluecar.bmp"

'*** Inline object on every trial
'Wait for vertical blank
display.WaitForVerticalBlank

'copy offscreen to actual screen
display.canvas.copy offscreen


The main thing is to copy all or most of the offscreen buffer to the screen,
that should take care of the flickering. That implements a software double
buffering system.
A complete separate question is how long it takes for the image to be copied.
In that sense the ideas presented by Georg about hardware double buffering as
implemented by MEL2 (only for very low-resolution modes) are relevant.

I have tried a little experiment by using an experiment I wrote in response to
Nicole's original question.
I just copied such an offscreen buffer using a 640 * 480, 16-bit screen mode.
Immediately after the inline I used a wait object without vertical blank
synchrony. According to the data file, the onsetdelay variable for that object
is 17 ms.
If the program waits until the image is copied before presenting the wait
object, this time should equal (or maybe be larger than) the time required for
copying the whole screen.

Do you think that is correct? How reliable is it? If you think I can trust the
data, I could also see what happens in higher-resolution display modes.

If it were correct, it would mean that the delay equals one refresh cycle (my
refresh rate is about 60). You can't go below that and still be sure the whole
screen is presented to the subject. This would make discussion about quicker
copying methods rather accademic, unless one is very interested in using very
high-resolution modes.

At any rate, MEL2 would never be better than E-prime: if you can use a
resolution low enough for MEL then you can also present the information in E-
prime as quick as possible for your hardware. You could even do it with much
better resolution modes: MEL2 can't handle the mode I've used and much less if
you want to use hardware double buffering methods which are only possible for
EGA modes, at least if you want two whole-sized screen buffers.

Please if I'm wrong or I'm missing something, please let me know.