This test is to determine the refresh rate of a given mode exactly and in so doing it also determines how long TimeDX should spend when it determines the retrace rate automatically for the Time Video Mode test.  Unless you notice the retrace rate determination in the Time Video mode test taking an inordinate amount of time (it should take a few seconds at most and on some machines it's so fast you can't ever actually see the test run) you can pretty much forget about this test (unless you are using an LCD flat panel display, see below) beyond making sure that it doesn't throw an error.  If you cannot get the test to run without flagging an error all other programs should be closed when using this test, particularly things like MS Word.  The BIOPAC Acquire program is also horrendous, until they change the program so it doesn't use every single CPU cycle even when it isn't doing anything DMDX and TimeDX are going to have a tough time doing accurate timing.

    The refresh rate test sets up two screens with the text "Refresh Rate <>" and "Refresh Rate ><" and flips between them as fast the hardware will allow, which should be at the refresh rate.   When the test is working properly you should see the sets of angle brackets imposed on each other, smoothly, there should be no flickering beyond the first few flips.  You should see four little Xs in a 2x2 grid that should be dimmer than the Retrace Rate text except at the centers of the Xs where they will have the same intensity as the Retrace Rate text. Sometimes a machine just gets flat out ornery and this test coughs and farts and never settles down, restart TimeDX and all is plain sailing again.  In the past when I experienced this problem it was directly attributable to MS Word, closing it removed all trace of instability.  These days it's usually a LCD flat panel running at a non-native resolution (see below) adding yet another complicated wrinkle to everything.  Although the display might be flickering all over the place TimeDX might in fact determine the retrace interval correctly because it's the panel itself causing the flickering, not the computer and the user has to recognize the visual indications of poor testing.
    Another good check is that a number of monitors these days sense what the refresh rate is and store brightness, contrast, etc, parameters for each video mode, when you adjust these the monitor usually displays the current refresh rate in Hertz, invert this number and that is the number the Retrace Rate determination code should be coming up with, if it's not you need to tweak it's parameters until it does.
   
    The user can control how accurately (or how long) this test takes by raising or lowering the SD field.  This value is stored in the registry and used by the Time Video Mode Test when it determines what the automatic timing values should be for any given video mode.   The version 5 Refresh Rate test operates by recording the intervals from successive Present() (Direct3D) or Flip() (DirectDraw) operations and calculating the SD of those intervals.  When the requested number's deviation falls below the specified SD the test stops and returns the retrace interval as the average of those samples.  The default value of 60 cycles and an SD of 0.1 typically yields values that are accurate to 0.01ms.  On some machines this may be unattainable but on everything I've tested so far it's been fine.  If the test refuses to finish hitting a key or clicking the mouse will terminate it, however the version 5 code usually still returns a pretty accurate value even then.  If your machine takes too long or never settles down enough to finish then you will have to raise the SD till it does.
   
    The user can also flag whether the routine is not to check for other activity as the test is running.   I stuck this is in in the hope that perhaps I could block MS Word's interference with it but alas it doesn't look like it -- the design of the version 5 code renders this consideration moot in my experience however.   Checking the "Don't Bother Checking for Other Activity" checkbox stops the timing routine from processing windows messages while it's running, if checked you won't be able to abort the timing loop (so if you specified a really low SD you'll be waiting for a while) but there's less chance the timing loop will be interrupted.
   
    When using the default DirectDraw rendering path there is a possibility that the hardware may be cheating on flips (see flip waiting time at the end of the Video Mode selection), by buffering a number of flips up so benchmarks look better.  If this check box is grayed out you're using the Direct3D rendering path.   While the version 5 SD based code renders such cheating irrelevant I left the "Read Between Flips" option in there because I don't want to delete code that could be useful some day on some future setup that I can't predict currently.



LCD Flat Panel Displays.

    The prevalence of TFT or LCD flat panel displays these days introduces new and critical issues for tachistoscopic displays when using the non-native resolutions of the flat panel and it just so happens that the Refresh Rate test is a really good way of detecting whether you've actually selected said native resolution or not.  When a flat panel sees a video signal that's not at it's native resolution it has to render that video data into it's own resolution, this takes time and thus lags the display and can also drop whole frames of video data so selecting the native resolution as the video mode becomes critical.  The Video Mode dialog has a button to select the desktop resolution which is normally but not always the native resolution and in addition there are flat panels that only operate correctly at particular retrace rates so the video mode selection really has to be checked against the monitor in real time to see whether the monitor is screwing things up and the Refresh Rate test is a really good test because it presents a continuous train of different displays which the unaided eye can easily detect changes in.  So when the monitor drops a frame you see the display flicker.  Which presents a bit of a problem as a failure anywhere produces the some sort of flickering display, you can have cheating drivers (or other more severe problems) producing flickering and you can have the monitor producing it leaving the poor user with even less clue as to what's happening.  Principle difference here is that TimeDX can time the display correctly while it's flickering due to monitor based non-native resolution factors whereas the other flickering (caused by drivers or worse) won't get timed correctly till the SD is raised.  So if you see the Refresh Rate test correctly determine the refresh rate in a reasonable period of time but the display is still flickering you can be sure you're not using the native resolution of the flat panel as the flickering is being caused by the panel.  To cap it all off I've seen recent examples of flat panels that operated at 60, 70 and 75 Hz, some of them only operate correctly at 60 Hz, others at 75 Hz.  So the Refresh Rate test becomes your acid test for determining what display you should use.  If the Refresh Rate test is operating quickly and giving the right sort of results but the display is flickering the display resolution and or the refresh rate isn't to the monitors liking.  Get it all right and you'll finally see an even display.  All is not lost however, even if you get everything wrong (assuming you get half way correct video timing parameters in the Vertical Retrace Sync test) the worst error DMDX is going make is still only a couple of ticks or so so all of this only really matters to people doing masked primes and other sorts of tachistoscopic displays.  And color depth doesn't appear to be a variable so you've still got the choice of 16 or 32 bit displays.

    There's a rather good article on LCD flat panels on X-bit labs:  Contemporary LCD Monitor Parameters: Objective and Subjective Analysis.  Saved version is here.


TimeDX Index.