flicker

Georg Odenthal odenthal at soz.psychologie.uni-konstanz.de
Mon Oct 20 13:42:25 UTC 2003


I've recently tried to create subliminal priming experiment with
E-Prime and also found out about the screen flicker. So I had to
abandon this project using E-Prime and went back to MEL2 where you can
avoid this screen flicker by using double buffering or a color
switching trick (explained later).

It's strange that PST didn't include the double buffering feature from
MEL2 in E-Prime since it is such a useful technique for subliminal
priming studies.

Double buffering refers to the possibility to store two different
screens in two different screen banks in the memory. Modern graphics
cards hold several frame buffers in their 64MB or 128MB of frame
buffer. Switching between one buffer and another can be done with a
few commands in virtually no time.

Unfortunately this feature doesn't seem to be included in E-Prime.
I wasn't able to find any information on creating and switching
between frame buffers in the E-Prime Reference guide. On page 97 of
the Reference Guide there is the method
"DisplayDevice.RestoreVideoBuffers (method)" listed, but neither in
the manual nor in the E-Basic help seems to be any more information on
that.

When a Display Object is painted using the DisplayObject.draw method
a software creates the screen display or copies a preloaded image from
the memory to the screen. This can take a lot of time depending on the
screen size and the color depth.

I've written a small program to demonstrate how much time this Draw
command can take. I'm including the E-Basic InlineObject with this
email. Besides that you need to create two TextDisplays called Black
and White (one with Black background and one with White background,
both are opaque. Make sure to set the Default Duration to 0)

Create another TextDisplay called CollectResp, set the Duration to 0,
EndAction to "(none)", TimeLimit to 10000 (for 10 seconds) and add a
Keyboard input collecting any key response.

Insert the CollectResp object as first item into SessionProc and the
Inline Script as second.

Enter the following commands into the Inline Script:

'Repeat loop until a keyboard response was made
While CollectResp.InputMasks.IsPending()

        'Wait for frameflyback
        display.waitforverticalblank
        'Display black background
        Black.draw
        'Wait for frameflyback
        display.waitforverticalblank
        'Display white background
        White.draw
        'Give the computer some time to collect a keyboard response
        sleep 1
wend

When you run this script your screen will present you a very quick
black and white flicker. But usually you will also see that a part on
top of the screen looks somewhat displaced. This displacement is a
measurement of the time the draw method takes to paint the black or
white background on the screen. This time is dependent on the speed of
the computer, on the refresh frequency of the screen (e.g. 60 Hz,
75Hz, ...) and on the screen resolution as well as on the color depth
of the screen.

In most cases you cannot change the speed of the computer (unless your
lab computers have a faster processor than your E-Prime development
computer). The refresh cycle of the screen is dependent on the
manufacturer and model of the screen and usually cannot be changed as
well.

What you can do is change the screen resolution and color depth. To do
that double click on the Experiment Object, go to the Devices tab,
double click on the Display item. A window with the name "Edit
DisplayDevice Properties" should pop up.

There you can change the screen resolution and color depth of the
program. The default values are 640 * 480 with 16 bits color depth.
Try for example to switch the resolution to 1024 * 768 with 24 bits
color depth. When you run the program the displacement on top of the
screen will be a lot larger, because it takes a lot more time to fill
a screen with 1024 * 768 pixels with 24 bit color depth.

If you change to 640 * 480 with 8 bits color depth the displacement
gets a lot smaller.

Why is that so?

A screen resolution of 640 * 480 means that there are 640 points in
each horizontal line on the screen and there are a total of 480 lines
per screen. That is 640 * 480 pixels = 307200 pixels.

The color depth 16 means that you can display one of 65536 colors in
each pixel. A byte takes up 8 bits, that is 16 bits means each pixel
has two bytes on the screen. So the 307200 pixels need two bytes each
that is the screen memory is 307200 * 2 = 614400. In kilobytes that is
614400 / 1024 = 600 kb per screen. This is not very much memory
compared to the main memory of modern computers and graphics cards.
Copying 600 kb from the memory to the screen doesn't take up too much
calculation time.

Now how much memory does the computer need to copy from the memory to
the screen in the 1024 * 768 example.
Pixels per screen: 1024 * 768 = 786432 pixels
Color depth 24 bits: 3 bytes per pixel
Memory taken: 786432 pixels * 3 bytes/ pixels = 2359296 bytes
in Kilobytes: 2359296 / 1024 = 2304 (equals 2.25 mb).

Copying 2.25 mb to the screen takes a lot more time since it's almost
four times as much memory as the 640 * 480 resolution.

I've also tried to display images that were pre-loaded into the
memory, but I've received exactly the same effect. The displacement
line showed up at virtually the same place as in the TextDisplay
example above.

This displacement line shows the position where the routine that
copies the screen display from the memory to the video ram in the
graphics card overtakes the video beam that displays the pixels in the
video ram on the screen. That is on top of the displacement line you
still see the previous frame whereas below the displacement line the
new frame is being painted. This results in a partial display of two
different images.

If you want to display subliminal stimuli on the screen this
displacement line can become a huge problem if is within the stimulus
you want to display. In this case the subjects would only see the
bottom part of the stimulus on one frame and then the top part of the
stimulus and the bottom part of the mask in the next. (And then the
top part of the mask in the screen after that).

This can probably render your subliminal priming useless or at least
make your discussion difficult since you have to argue in the
discussion that presenting stimuli that are split in half still have
the same effect than stimuli that are presented as a whole.

We wanted to create study where words are presented subliminally in
the parafoveal field. But since E-Prime couldn't guarantee that the
words are always presented as whole we switched back to MEL2 to create
this study in MSDOS.

Unless there is a method in E-Prime to flip between two different
screen buffers in the video RAM of the graphics card I won't try to
create subliminal priming studies with E-Prime again. The danger of
loosing the data of a study with a hundred or more subjects due to this
displacement bug is too costly for our lab.


For displaying simple stimuli there is a different method than copying
pre-loaded images on the screen: the color switching trick.

This color switching trick is only possible in a 256 (8-bit) color
mode. With it you can present up to 8 different stimuli in a short
succession without running into the problems above.

In this trick you create stimuli with a program that supports an XOR
(or also called EOR) overlay mode for painting text on the screen
(e.g. MEL2 is capable of doing that with the SET_RASTEROP_MODE
command.) E-Prime doesn't offer an XOR overlay mode, it has only
ebROPModeCopy or ebROPModeMerge though.

XOR is short for eXclusiveOR. If you paint something on the screen,
the bits of each pixel will only be painted unaltered if the
background bit is 0. Else the bit will flip it's value (e.g. 1 and 0
or 0 and 1 will become 1 and 1 and 1 will become 0). If you paint
two words in different colors over one another the result will look
like an abstract painting. But by redefining specific colors you can
make either one or the other word visible. (it also with 3 up to 8
words.)

We used this method in MEL2 a lot since the double buffering was only
available in very weird screen modes (e.g. 640 x 350) in which text
looked very deformed.

The trick with this method is to know which colors you need to
redefine. But there's a simple solution:

A byte contains of 8 bits, e.g. 10010001 (this is also called binary
notation). The leftmost bit is the MSB (most significant bit) and has
a value of 2 to the power of 7 = 128, the rightmost bit is the LSB
(least significant bit) and has a value of 2 to the power of 0 = 1.
The bits in between have the values 64, 32, 16, 8, 4 and 2
respectively.

If you overlay text in the XOR mode in any of these 8 values, you will
have a distinct color bit for each of the 8 different stimuli. That is
if you paint a prime in color 2 (as byte: 00000010) on the screen and
overlay it with a target in color 8 (as byte: 00001000). The color
where both text overlap with one another will be 8 + 2 = 10
(00001010).
So if you want to display the prime you need to set the RGB values of
the color 8 to the RGB values of the background color and set the
values of both, color 2 and color 10 to the foreground RGB values.

For the target you need to set the color 2 to the background color and
colors 8 and 10 to the foreground color.


If you want to display 3 different words in quick succession you can
for example select the colors 1, 2 and 4. If you want to display the
first word set:
1, 3, 5 and 7 to foreground and 2, 4 and 6 to background

for the second word set:

2, 3, 6, and 7 to foreground and 1, 4 and 5 to background

for the third word set:

4, 5, 6 and 7 to foreground and 1, 2 and 3 to background

With every additional stimulus you add to this scheme the numbers of
colors you have to redefine doubles. So if you want to display 5
different stimuli you need to redifine 31 colors for each word with 8
stimuli you need to redefine all 255 colors for each word.

Switching colors is in E-Prime a lot faster than copying complete
screens to the video ram. You can use the DisplayDevice.Palette method
to set all 256 of a 8 bit color mode. I've written a small program
that does just that. I will just include a part of the InlineScript
since it is too large to be copied into this email as a whole:

Dim thePal As Palette
Dim i as Integer
Dim factor as Integer
Set thePal = Display.Palette

Dim arrEntries(255) As PaletteEntry
Dim prime(255) As PaletteEntry
Dim mask(255) As PaletteEntry
thePal.GetEntries 0, 256, arrEntries

[... 'Color redefinition is done in this omitted part]

'Wait for frameflyback
display.waitforverticalblank

'Set the palette
thePal.SetEntries 0, 256, arrEntries

'Repeat loop until a keyboard response was made
While CollectResp.InputMasks.IsPending()

        'Wait for frameflyback
        display.waitforverticalblank

        'Set the palette and wait for keypress
        thePal.SetEntries 0, 256, prime
        sleep 1

        'Wait for frameflyback
        display.waitforverticalblank

        'Set the palette and wait for keypress
        thePal.SetEntries 0, 256, mask
        sleep 1

        'Wait for frameflyback
        display.waitforverticalblank

        'Set the palette and wait for keypress
        thePal.SetEntries 0, 256, arrEntries
        sleep 1
wend


If you're interested in the program, I can send you the whole program
including the test screen with the two stimuli as a ZIP archive.

The drawbacks of this color switching trick are besides the
increasing number of colors you need to redefine are also, that you
are limited to 8 colors and that your text cannot use anti-aliasing
(smoothing) of the font, since this adds several colors (usually gray
nuances) to the image.

But as long as E-Prime cannot perform real frame buffer switching this
seems to be the only method available to ensure a quick and complete
display of subliminal stimuli.


If you have any questions or are interested in the programs discussed
in this email you can write to the address below.

Best regards,
 Georg Odenthal


 =========================================================================

Georg Odenthal (Dipl.-Psych.)             University of Konstanz
+49 (0)7531 88-2872                       Department of Psychology
odenthal at soz.psychologie.uni-konstanz.de  Social Psychology and Motivation
http://www.socpsych.uni-konstanz.de       78457 Konstanz, Germany

 =========================================================================



More information about the Eprime mailing list