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.
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
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