TIMING: Fast/Single Refresh Presentation in E-Prime [18033]

This article applies to:

E-Prime 3.0

E-Prime 2.0

E-Prime 1.x

Detail
E-Prime is capable of fast presentation rates, including single refresh displays. However, certain considerations regarding your specific task and machine hardware must be made in order to achieve the best results.

First, you should always use PreRelease before objects that present sound or image stimuli in order to achieve the fastest loading time. Onset delays in an experiment typically account for the amount of time needed to wait for a vertical blank, immediately preceding drawing time. If the objects have not already been set-up and loaded (during the PreRelease), this occurs during the OnsetDelay time. Thus, where a ready-to-run (i.e., pre-loaded) object would simply wait for the next vertical blank, an object with unloaded image or sound stimuli cannot do so, and must set up, load, and then wait for the next vertical blank. This can last as long as several refreshes, if not properly accounted for.

PST strongly recommends reading through OVERVIEW: Timing in E-Prime [23285] and it's linked articles for a complete reference on timing issues, image presentation, and PreRelease in E-Prime.

If all of the images in your experiment are the same size, ensure that the ClearAfter property of the object that presents them is set to "no". If E-Prime does not have to clear the screen before each new image is loaded, faster loading time is facilitated. Furthermore, if it is a viable option, cutting down the size of the images would likely allow the images to load faster, as would setting stretching/shrinking properties within E-Prime to "No". The smallest frame size possible for your images should also be used (for example, you do not need to use a frame size of 100% on an ImageDisplay object that just shows a small fixation).

While E-Prime can facilitate faster image loading, the loading of bitmaps is also dependent on your video card and monitor speed, as well as on the nature of the stimuli. As stimuli get larger and more detailed, the drawing time naturally increases. The best indication of the loading time required for each stimulus is the OnsetDelay Time Audit logging property.

Upgrading your video card can also have a positive effect on timing of image presentation. When images are accessed from the system RAM, you may experience a delay as compared to when images are accessed from video RAM. This is not a restriction of E-Prime, but of the hardware. Our developers suggest using an AGP video card if you do not already have one installed, or increasing the amount of video RAM. By default E-Prime will load all the images in video RAM first. Once the memory is exhausted, E-Prime will start storing the images in the system RAM.

An important fact to keep in mind is that the actual duration of an event in E-Prime will always be a multiple of the refresh rate. On a machine with a refresh cycle of 14ms, for example, an event in E-Prime with a duration of 20ms will actually take 28ms. You should set the Duration property of your objects accordingly. Remember that the refresh rate that is logged in the data file is read directly by E-Prime through its low-level DirectX access. It is not reported by Windows and therefore may be different from what Windows reports.

The general rule of thumb when working with critical timing is to subtract 10ms from the intended duration to account for delays that result from waiting for the next vertical blank (the beginning of the refresh cycle). This, alone, may help you minimize the OnsetDelays in your experiment. Note that this only applies to E-Prime 2.0.8.x. Subtracting 10ms in E-Prime 2.0.10.x and later is not necessary due to RefreshAlignment. Please see TIMING: RefreshAlignment locks into nearest refresh vertical blank to promote timing accuracy [18035]

Please also keep in mind that the time it takes for a single refresh may not be a whole number. That is, it may go out many decimal places. For instance, the time for a single refresh on a 100Hz monitor is 10ms. The time for a single refresh on a 75Hz monitor is ~13.3ms. A 65Hz monitor takes ~16.67ms. The only time the actual duration of an object would not be a multiple of the refresh rate is if that object was not set to Sync with the Vertical Blank. That would mean that the object may begin to be drawn mid-way through a refresh, and you would thus encounter tearing (part of the previous display, and part of the current display on the screen at the same time). As such, we recommend always being in sync with the vertical blank.

Lastly, it is also important to keep in mind exactly what the OnsetTime property is telling you. The OnsetTime property will give you a timestamp of the exact time in which the display began to draw. That means the time in which the display began to draw at the top left of the monitor. E-Prime cannot tell you when each piece of the display was put on the screen; only when a particular object began to draw. Take, for instance, a fixation cross display: the OnsetTime property of the object states that it began to draw at 3000ms from the beginning of the experiment. Its OnsetTime is exactly 3000. However, as it is a centrally placed fixation cross, it will not have actually been drawn until up to ½ the length of a refresh after the OnsetTime. So, if the refresh rate of the monitor is 100Hz, the actual fixation cross will have been drawn around 3004-3005ms.