-- what --

this is a trivial example of a fill limited application.

-- overview --

use themiddle mouse button to zoom in/out on the scene. notice that
the frame rate changes in connection with the zoom factor. as you get
closer, to the geometry, the framerate slows, as you get farther away,
and the triangles shrink, the framerate increases. this is the classic
test of a fill-limited application. this test could also be performed
by shrinking the window size and noticing if the framerate
increases. the window-shrink-test is not without caveats and those
caveats are detailed in the course notes.

-- test --

when you press the 't'-key, a sequence of frames are rendered and
timed. the resultant time and triangles-per-second achieved are
printed to stderr.

when you press the 'g'-key, a low-geometry count scene (but high fill
demand) is drawn. when the 'G'-key is pressed, a high-geometry count
scene (and approximately similar fill demand) is drawn. specifically,
an additional small cube (12 triangles) isdrawn with every large
triangle. this increases the triangle count by a factor of 12. the
resultant effect on framerate can be seen immediately by moving the
model with the mouse-based commands listed below.

-- results and why --

if you are fill-limited, you'll see the overall test time vary little
between the extra-geometry-on/off cases. but you will see the triangle
rate increase dramatically. this implies that we're not geometry
bound, that is, we can add more geometry and have little effect on our
framerate, provided that we also keep the fill demands low.


-- notes --

all drawing is done in single-buffer mode to avoid frame quantization
issues as described in the course notes.

-- commands --

-- mouse commands
l - rotate the scene
m - zoom (scale) the scene
r - pan the scene
-- keyboard commands
r - reset all parameters
G - set high geometry load
g - set low geometry load
t - run timing test to generate triangles-per-second
h - display this help
? - display this help
