flicker
Tony Zuccolotto
anthony.zuccolotto at pstnet.com
Tue Oct 21 13:17:43 UTC 2003
Georg,
I will try to create a more in depth response later this week, but you
essentially should be able to do what you want in E-Prime and eliminate
the flicker.
You are correct that the hardware based page flipping that was directly
supported in MEL is not there in the exact same form in E-Prime.
Support for multiple offscreen buffers/canvases however is there and is
more powerful than what was offered in MEL. Without going into a lot
of detail, it was not possible for us to implement the hardware based
page flipping feature and have it coexist with the other operations of
all the other objects in E-Prime. For example, since E-Prime always
runs in graphics rather than text mode, we had to provide support for
echoing back responses over top of images better than was done in MEL.
Features like these were basically incompatible with the E-Prime model
without sacrificing the general performance of the system. Further, when
we initially attempted it, the performance of the hardware page flipping
vs Canvas.Copy was not significantly better on most video cards (e.g.
both were sub-millisecond).
I expect though, that the actual problem you are running into is that
the Windows drivers for many video cards perform bitmap fills/transfers
from the bottom up, thus rather than the copying of the image data
starting at the top of the screen and filling down (while staying ahead
of the refresh), the image data starts at the bottom and fills towards
the top at which point the image fill and the refresh cross each other
and you may get something like you describing. E-Prime 1.1 included
advanced features that allow you to instruct the system to automatically
split these bitmaps up into smaller portions which are drawn starting at
the portion at the top of the screen.
Checkout the E-Prime Knowledge Base article
http://www.pstnet.com/e-prime/support/kb.asp?TopicID=1274 and/or
DisplayDevice.SegmentCopyHeight, DisplayDevice.SegmentCopyVerticalOffset
in the E-Basic help (E-Prime 1.1). In all instances I have been aware
of where this problem was observed, these commands could be used to
minimize or eliminate the visual problem at the top of the screen.
Thanks,
Tony
*** DISCLAIMER: ALL VIEWS EXPRESSED ARE MY OWN AND DO NOT NECESSARILY
REFLECT THOSE OF PSYCHOLOGY SOFTWARE TOOLS ***
Anthony P. Zuccolotto
Vice President
Psychology Software Tools, Inc.
2050 Ardmore Boulevard
Suite 200
Pittsburgh, PA 15221-4610
Phone 412-271-5040
FAX 412-271-7077
Email anthony.zuccolotto at pstnet.com
Internet http://www.pstnet.com
> -----Original Message-----
> From: Georg Odenthal [mailto:odenthal at soz.psychologie.uni-konstanz.de]
> Sent: Monday, October 20, 2003 8:42 AM
> To: eprime at mail.talkbank.org
> Subject: Re: flicker
>
> 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