Adding new infrastructure features to glean

(Thanks to Neal Tringham for most of these.)

On all systems

It might be useful to add a command-line option that would force glean to overwrite an existing database, which is something that it refuses to do now. Probably the best way to implement this would be to recursively delete the old results directory before creating a new one, since the set of tests may have changed in unpredictable ways. This code would be system-dependent, so distinct versions would be needed for all operating systems.

Internationalizing the test summary and results messages would be helpful.

On Windows

Non-default color depths

glean and the other tools in the suite run only at the default screen color depth. It would be useful to add a command-line option that switches to a new depth, because some graphics cards accelerate only some color depths. Note that the usual method for doing this (ChangeDisplaySettings) can't be guaranteed to work on Windows 95, and using DirectDraw to change the depth causes some drivers to crash. However, it would be valuable on Windows 98 and perhaps on Windows 2000. Documenting the need to switch color depths manually on Windows 95 (and Linux!) would cover the other cases.

Supporting old standalone 3D cards

glean uses the normal ICD mechanism to access the OpenGL driver. This means that graphics on older standalone cards (such as 3Dfx Voodoo 1 and Voodoo 2) will never be accelerated, and the test results will be valueless on those cards. Probably the best solution is to use the upcoming GLSetup API, which allows the proper driver to be loaded. If this is done, we'll need to make sure that tests which create more than one window are not run on the older cards.

A related issue is that GLUT also doesn't support standalone cards, so the tools which use it need to be modified to use the GLSetup API or some toolkit other than GLUT.

Note that there are further issues with supporting old 3Dfx cards. Neal Tringham reports:

The problem is that even if the driver's been installed, the 3dfx card might have been taken out later, leaving a driver which faults as soon as you load the 3dfxvgl dll. As far as I know, the only truly safe way to deal with this is to check for the presence of the Glide dlls, load glide if they're present, and then use the Glide API (grGetNumBoards or something with a vaguely similar name) to actually detect the presence of the hardware. If its there, you should be able to load 3dfxvgl.dll safely.

Perhaps the GLSetup implementation will cover this.

Supporting multi-card systems

For systems with multiple graphics cards, it would be nice to have a command-line option that specifies the card to be tested. This could be similar to the display option used on X11-based systems.