Add a note about window map behaviour and the autotuning of nr of loops which
can conspire to make it look like clearspd is exposing an intermittent driver
bug...
diff --git a/progs/demos/clearspd.c b/progs/demos/clearspd.c
index 706e698..c9a4e26 100644
--- a/progs/demos/clearspd.c
+++ b/progs/demos/clearspd.c
@@ -1,4 +1,4 @@
-/* $Id: clearspd.c,v 1.4 2002/04/22 16:03:37 brianp Exp $ */
+/* $Id: clearspd.c,v 1.5 2002/10/31 12:38:32 keithw Exp $ */
/*
* Simple GLUT program to measure glClear() and glutSwapBuffers() speed.
@@ -61,6 +61,12 @@
glutSwapBuffers();
}
+ /* NOTE: If clearspd doesn't map it's window immediately on
+ * starting, swaps will be istantaneous, so this will send Loops
+ * towards infinity. When a window is finally mapped, it may be
+ * minutes before the first call to glutSwapBuffers, making it look
+ * like there's a driver bug.
+ */
if (t1-t0 < MinPeriod) {
/* Next time do more clears to get longer elapsed time */
Loops *= 2;