-! Note that those hacks (gears, superquadratics, escher, pipes, and
-! sproingies) will work best on a visual *half* as deep as the depth of the
-! screen, since that way they can do double-buffering -- on an SGI, you
-! should specify the 12-bit TrueColor visual (probably 0x29) instead of
-! letting XScreenSaver pick the visual itself (specifying "TrueColor" would
-! select the 24-bit TrueColor visual, and double-buffering wouldn't be used,
-! resulting in flicker.)
+! If your vendor doesn't provide real OpenGL, you might want to consider
+! building MesaGL, which is a free implementation -- GL is way cool.
+!
+! Note that those hacks (gears, superquadratics, morph3d, cage, moebius,
+! stairs, pipes, sproingies, and rubik) tend to work best on a visual *half*
+! as deep as the depth of the screen, since that way, they can do
+! double-buffering -- try it and see, but you will probably find that you
+! should specify the deepest visual that is half as deep as the screen.
+!
+! For example, on a screen that supports both 24-bit TrueColor and 12-bit
+! PseudoColor, the 12-bit visual will probably work best (this is true of
+! base-model SGI Indys: the 0x29 visual is the one you want.) Oddly, on SGI
+! O2s, (machines that have serious hardware support for GL) the 12-bit
+! PseudoColor visual looks awful (you get a black and white, flickery image.)
+! On these machines, the visual you want turns out to be 0x31 -- this is but
+! one of the eight 15-bit TrueColor visuals (yes, 8, and yes, 15) that O2s
+! provide. This is the only visual that works properly -- as far as xdpyinfo
+! is concerned, all of the 15-bit TrueColor visuals are identical, but some
+! flicker like mad, and some have deeply weird artifacts (hidden surfaces
+! show through!) I suppose these other visuals must be tied to some arcane
+! hardware feature... Your mileage, therefore, may vary dramatically.