From: Spatial Vision, 1997;10(4):36, special issue on "CRT Displays in Vision Research"
An Introduction to Accurate Display Timing for PCs under "Windows"
Alex Gofen and Manfred Mackeben The Smith-Kettlewell Eye Research Institute, 2232 Webster Street, San Francisco, CA 94115
3212 words, 314 lines
Short title: PC Display Timing
Please send correspondence to: Alex Gofen c/o SKERI, 2232 Webster Street San Francisco, CA 94115, USA Fax: +415 / 561-1610
Gofen & Mackeben, PC Timing under Windows
email:
[email protected] (Gofen) or
[email protected] (Mackeben)
page 2
Gofen & Mackeben, PC Timing under Windows
page 3
Abstract As the use of computers for delivering stimuli in vision research has become ubiquitous, there is an obvious need for accurate timing of display monitors without the use of expensive hardware extensions. If a user should decide to program an application in the increasingly common “Windows” operating system for IBM PCs and compatibles, a software solution for this problem is not obvious any more. The goal is to achieve display durations down to one single video frame. This article describes several approaches and a tested solution designed to run on any PC or compatible under Windows 3.1/95 regardless of the video card used. This creates new possibilities for low-cost implementation of visual experiments for laboratory and classroom use.
Gofen & Mackeben, PC Timing under Windows
page 4
Introduction Duration is one of the fundamental properties of any visual stimulus. It can determine whether a stimulus is detected or whether a related task can be solved. This is not only true if fundamental variables (e.g. duration, size, contrast, velocity) are set so that the physical properties of the stimulus are near the detection threshold, but also above threshold (see e.g. Varner et al., 1989; Baron and Westheimer, 1973; Kahneman, 1966). The issue of duration becomes particularly relevant if visual stimuli are generated by a computer, because the durations can be determined only as a multiple of the interval that is necessary to produce one screen full of raster image, the "video frame" duration. This interval can vary between 1/90 and 1/50 sec, and is approximately 15 msec for commonly used equipment. As the human eye is able to detect and recognize stimuli of even shorter duration, accurate timing of the display is critical for these experiments. It should be noted that each dot of the screen raster is, in fact, only ON for less than 1 msec due to the short decay rates of modern computer monitors (Mogg and Bradley 1995). In order to maximize accuracy, the output of a visual stimulus must be synchronized with the scanning frequency of the video card (our use of the word "output" includes all algorithmic processes needed to create the image and to send it to video memory). If synchronization is ignored in the generation of a visual target of just one frame duration, the target may appear cut horizontally. For durations of 2 or 3 frames, the brightness of the target may look uneven because the first or last image frame was incomplete. (Such a distortion will occur with a probability of n/N, where n is the number of scan lines necessary to produce the target and N is the number of scan lines on the whole screen). As timing inaccuracies have the largest perceptual effects on stimuli of short durations, the ultimate test is to measure the output while stimulus duration is set to one frame length (see below, Practical Tests).
Gofen & Mackeben, PC Timing under Windows
page 5
Techniques for displaying stimuli synchronized with the scanning rhythm of the video card in the MS DOS environment have been described elsewhere (Haussmann 1992; Diesch, 1994; Brisinski 1994; Mogg and Bradley 1995). The principle implemented in those papers was multibuffering, i.e. preparing two or more complete screens in the video buffer and switching the origin at the moment when scanning begins. This was easy to do in the standard EGA and VGA modes with Borland’s Pascal Graphic Unit, and it will become standard routine again under the Windows 95 game Software Development Kit (SDK), a collection of high-lebel software routines, one of which enables the user to switch video screens (Edson 1995). Under previous versions of Windows, specifically Windows 3.1, the multibuffering techniques could not be implemented for any SVGA card in high-level programming languages. The current paper addresses the needs of those who need accurate display timing and, at the same time, want to take advantage of the graphical solutions provided by Windows 3.1 (or Windows 95, if the Game SDK is not used) for their laboratory or classroom applications, or who need to implement interactions of a customized program with other Windows-type applications. Below, we will develop an alternative approach based on calculated lagging of the display behind the scanning rhythm. Video Display Basics We assume that the video card and the monitor work in the Non-Interlaced mode, because it is the only one permitting the display of undistorted images for just one frame. To that end, the following conditions have to be met: 1. The time needed to display the image or to restore the background must be shorter than the frame duration; 2. The display of the image must start at such a moment that it safely lags behind the reading of video memory without interfering with it; 3. The restoring of the background must also start at a moment that lags behind the reading of video memory, only one frame later.
Gofen & Mackeben, PC Timing under Windows
page 6
Hence, this requires a software function that either returns the number of the current scan line or causes a delay until the scan line with a specified location is reached. Secondly, a procedure to perform delays with sufficient accuracy is needed (the DOS/WINDOWS clock is modified only every 55 msec, which is too coarse for this purpose). We will discuss these problems separately in the following two sections. The Scanning Rhythm of Video Cards In modern computers, the periodic scanning process is controlled by the video card, not by the video monitor. To the CPU of the computer, this looks like a series of external real-time events that it cannot control. It can, however, detect these events and respond to them. The detection is possible by mapping certain video card registers onto specific ports of the computer. According to Ferraro (1995) and Wilton (1994), there is no accessible register of video cards that contains the number of the currently scanned line. However, Wilton (1994) suggests using the special I/O status register 1 that is accessible through port 3DA, bit 3 of which indicates the occurrence of the so-called "Vertical Non-display Interval" (VNI) and is set to 1 during the VNI and reset to 0 otherwise. The VNI is the time during which the electron beams scan the lower border and then retrace upward to scan the upper border (typically the border is black). Consequently, it is easy to design a procedure that waits until the start or the end of the VNI: procedure WaitVNIend; const bit3 = 8; var prev, cur : byte; begin cur := Port[$3DA] and bit3; repeat prev := cur; cur := Port[$3DA] and bit3 until (prev>0) and (cur=0) end;
Gofen & Mackeben, PC Timing under Windows
page 7
Accurate Time Measurement A procedure waiting until a specified line is scanned has to wait for the end of the VNI and then continue to pause for an interval or fraction of the frame that is proportional to the specified line number. This requires a procedure that pauses for the specified duration with sufficient accuracy, because the Windows timer, which is actually the DOS timer, is not accurate enough. For Borland’s DELPHI environment, one can use a piece of code called "StopWatch" for timing (Holms, 1995), that is available free of charge via Compuserve. In DELPHI, the user can simply drag and drop it into the necessary form. Furthermore, the article and the files in the Compuserve library also provide the assembler source code, which can be translated into other languages. This routine allows the design of a simple procedure for waiting a specified interval with an accuracy of 25 µsec. Holms also provides a "ProfilingStopWatch" component for measuring elapsed time between several lines of the source code with even higher accuracy (3 µsec). The following example of a Delay routine implements the StopWatch component: procedure TYourForm.Delay(interval : real); begin with StopWatch1 do begin Reset; Start; repeat until ElapsedTime >= interval; Stop end end;
If finding or implementing the StopWatch component is for some reason not easy, this Delay procedure may be substituted by a subroutine like this: procedure Delay1(interval : real); var k : longint; begin Counter := Round(interval*Coef); for k := 1 to Counter do {nothing} end;
Gofen & Mackeben, PC Timing under Windows
page 8
The value of global variable "Coef" must be determined in a calibration subroutine using the coarse system timer for an interval of, for example, 1 or 2 seconds, where "Coef" means the number of iterations counted by this short loop during 1 second. The actual duration of the pause produced by the procedure Delay1 may not be timed as accurately as the one based on StopWatch, because the running time of the same loop may vary due to interventions by system interrupts (e.g. the timer). Our measurements showed that the system timer interrupt takes 0.8 msec for an 80 MHz 486, which was quite acceptable for our purposes where typical interval durations are 15 msec and longer. A procedure waiting until the specified screen line is scanned may thus look like this: procedure WaitLine(LNum: integer); begin WaitVNIend; Delay(LNum/Height*FrameDuration) end;
Here is an example of the implementation of this procedure in a program that displays images for the time interval StimulDuration.:
Font.Color := clForeground; WaitLine(yTxt + 200);
{the goal is that scanning be ~200 lines ahead}
TextOut(xTxt, yTxt, Txt);
{in Foreground color}
Delay(StimulDuration); Font.Color := clBackground; TextOut(xTxt, yTxt, Txt);
{in Background color}
Display Time Requirements The remaining problem is to output images fast enough, so that this process takes less than one frame and safely lags behind the scanning. The required time depends on the methods of creating
Gofen & Mackeben, PC Timing under Windows
page 9
(modifying) images, their sizes, and the methods of eliminating delays caused by the operating environment. Image Size and Methods of their Creation. There are at least five different ways to display images: They are, ordered by their speed: 1. switching the video buffers containing the images; 2. outputting small images as bitmaps (the smaller the image, the shorter the time needed to move it!); 3. outputting text as fixed or scalable font; 4. drawing lines and shapes; and 5. flood filling. The actual time requirements depend on factors like CPU speed, whether the video card processes scalable fonts internally, and how many lines and shapes comprise the image. Some experimenting will be needed to determine the actual values for specific equipment. For example, drawing a wide diagonal across the whole screen or flood filling of a very narrow image is definitely faster than outputting the bitmap of the whole screen. Furthermore, when outputting scalable fonts of big sizes, the fonts with thinner letters may take less time because the thick parts of letters may require flood filling. The fastest method under any conditions is switching the video buffers. Switching video buffers has become possible from high level languages by the introduction of the Windows 95 Game SDK for speedy animation (Edson, 1995). Until now we have considered only the net time required by the drawing algorithm itself. However, any version of Windows itself lengthens the time, which is an obstacle to synchronizing software execution with real time events, as the system intervenes with its own activity during each attempt to perform an I/O operation (or even during the computing process). Thus, the time taken by an I/O operation under Windows may be much longer than the duration of the operation itself. To overcome that, a mechanism is needed that assigns the system's highest
Gofen & Mackeben, PC Timing under Windows
page 10
priority to the application for the short time segment, during which the synchronizing of the display must occur. This necessitates different approaches for the different operating environments: Windows 95 and Windows NT. This system provides such a mechanism by the assignment of real time priority (a value between 16 and 31) to a certain “thread” of the user application (see, for example, the API functions SetThreadPriority, GetThreadPriority, Goodman, 1995, p. 144). The real time priority must be assigned just before the execution of the statements that wait for a certain scan line and output an image, and must be restored to normal priority immediately after that; assigning the highest priority to a certain thread for a long time may hang up the system. Windows 95 and Windows NT also allow using the buffer switching technique to accelerate image modification. Windows 3.1. According to Livingstone (1992), there is no way to control the priority for one of several coexisting applications under Windows 3.1, as well as to change the priority in different running moments of one application. There are only such parameters like MINTIMESLICE and WINTIMESLICE in the SYSTEM.INI file accessible through the Control Panel’s 386-Box, but they are responsible for switching frequency and time slices between DOS and Windows applications: the time slices for running concurrent Windows applications remain beyond the user’s control. To minimize interference by Windows, all other Windows and DOS applications need to be closed, except the one which is real-time critical. This approach will be discussed in the next chapter. Practical Tests We set the goal to reliably display images with one frame length duration (the hardest case), even under Windows 3.1 and without any priority control. For this purpose, we used an existing application that we had developed in Borland’s DELPHI (desktop 16 bit version). It runs under both Windows 3.1 and 95 on an IBM PC 486 DX (100 MHz, Video Card Z-S3 805 (S3 Inc.), resolution mode 768x1024, 70 Hz non-interlaced).
Gofen & Mackeben, PC Timing under Windows
page 11
The software displays scalable letters or words of 10 to 100 pixels height for a short time. To monitor the physical presence and actual duration of a letter on the screen, we used analog hardware in connection with a second, independent PC. This conservative approach was taken to exclude the chance of any interference between the image-generating and the measuring process. A simple electronic circuit was fed a signal by a photo diode that was glued to the monitor screen. The signal was subsequently low-pass filtered, amplified and shaped by a one-shot (monostable multivibrator) circuit, so that each displayed frame generated one square pulse. These pulses were received by the second computer’s serial port, detected by a simple test program, and the frame count for each trial was written to a file. Thus, a predetermined number of trials (typically 250) could be run in rapid succession and the results could be subjected to statistical analysis. This device could not detect the occurrence of cut letters, but the cut letters could be easily seen by the naked eye. The output was always produced in the same location on the screen, right under the photo diode. The following precautions were taken to minimize intervention by Windows 3.1: 1. No applications of either DOS or WINDOWS type were loaded except the one generating the display. 2. The screen saver in Windows was deactivated. After that, the interventions that could still affect the performance were: interrupts by the system clock, processing of mouse movements and the keyboard, and writing auxiliary data into a file. We knew that our application does not write data to a file during trials, and during the running of the test trials, the keyboard was not touched and the mouse was not moved. Results: Under these conditions, and for letter heights smaller than 100 pixels, we ran 1000 trials each for stimulus durations of 1 and 3 frame lengths and saw NO trial in which the actually displayed (measured) duration was different from the desired value. Since at least the system clock interrupts the stream of events regularly, we conclude that the resulting interventions were brief enough not to affect our output operation.
Gofen & Mackeben, PC Timing under Windows
page 12
For comparison, we ran the same code without synchronizing, which immediately let cut letters appear with a frequency proportional to their size. In another experiment, we determined the time limits of the 'TextOut' API function. The results showed that, for letter heights of 200 lines and bigger, the duration of one frame was too short for such an output operation, even with synchronized output. The reason is that the standard procedure 'TextOut' needs a longer time to create letters of that size, probably because it involves flood filling. If the display of such large targets were required, one would have to apply the switching video buffer technique and create the necessary images in the secondary buffer in advance (for details see Edson, 1995). Conclusions Average PCs without hardware modifications, and independent of the display card, can be used for applications that require accurate display timing under any version of Windows. Inaccuracies and distortions can be completely prevented in Windows 95 and Windows NT, and can be minimized or practically eliminated in Windows 3.1.
Acknowledgments: This work was conducted as part of a development project supported by a grant to MM from the National Institute on Disability and Rehabilitation Research (NIDRR) and by the Smith-Kettlewell Eye Research Institute. The authors wish to express their thanks to Albert Alden and Steven Chung for their help with the analog
photo-electronic circuit and the pulse counting program, and to Amadeus
Colenbrander who made us aware of the paper by Edson. Delphi is a trademark of Borland International, Inc. Windows 3.1., Windows 95 and Windows NT are trademarks of the Microsoft Corporation.
Gofen & Mackeben, PC Timing under Windows
page 13
References Baron, W.S. and Westheimer,G. (1973) Visual acuity as a function of exposure duration. J.Opt.Soc.Am. 63, pp.212- 219 von Brisinski, I.S. (1994) Ultrafast display buildup with standard VGA on MS-DOS computers. Behav.Res.Meth.Instr.Comp. 26 (3), 335 - 336 Diesch, E. (1994) A high-resolution color graphic display four-channel software tachistoscope. Behav.Res.Meth.Instr.Comp. 26 (3), 331 - 334 Edson, Dave (1995). The game SDK for Windows 95 gives you direct hardware control for speedy animation. Microsoft System Journal, Vol. 10 (11), 15-40. Ferraro, Richard F. (1995). Programming guide to EGA, VGA, and Super VGA cards. Third ed., Adison-Wesley, Menlo Park, CA, 1600 p. Goodman, Kevin J. (1995). Building Windows 95 applications. M&T Books, New York, 564 p. Haussmann, R.E. (1992) Tachistoscopic presentation and millisecond timing on the IBM PC/XT/AT and PS/2: A Turbo Pascal unit to provide general purpose routines for CGA, EGA, and VGA monitors. Behav.Res.Meth.Instr.Comp. 24 (2), 303 - 310 Holms, Richard D. (1995). A StopWatch component. DELPHI Informant, Vol. 1 (5), p. 66-76 Kahneman, D. (1966) Time-intensity reciprocity in acuity as a function of luminance and figureground contrast. Vision Res. 6, 207-215 Livingstone, Brian (1992). Windows 3.1 secrets. Revised edition, IDG Books, Foster City, CA, 979 p. Mogg and Bradley (1995) Tachistoscopic applications of Micro Experimental Laboratory (MEL) used with IBM PC compatibles: Stimulus and response time issues. Behav.Res.Meth.Instr. Comp. 27 (4), 512 - 515 Varner, D.C., Rhodes,J .W., Kosnik, W.D., and Cartledge, R.M. (1989) Hue and saturation scaling of brief monochromatic lights. Invest.Ophthalmol.&Vis.Sci. 30, No.3 (Suppl.), p. 127 Wilton, Richard (1994). Programmer’s guide to PC video systems. 2nd ed., Microsoft Press, Redmond, WA, 496 p.
