+.B OpenGL Programs and Visuals
+Some of the graphics demos included with xscreensaver make use of the
+OpenGL (or MesaGL) 3D library, if it is available. It is possible (even
+likely) that \fIxscreensaver\fP's notion of the ``\fIbest\fP'' visual is
+not quite right for these GL programs.
+
+The odd thing about GL programs is that, unlike normal X11 programs, they
+tend to work best on a visual \fIhalf\fP 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, for these particular programs, you should specify the
+deepest visual that is half as deep as the screen. (See the discussion
+of the \fBprograms\fP resource in the \fIConfiguration\fP section, above.)
+
+For example, on a screen that supports both 24-bit TrueColor and 12-bit
+PseudoColor visuals, 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.
+However, 0x31 is but \fIone\fP of the \fIeight\fP 15-bit TrueColor visuals
+(yes, 8, and yes, 15) that the O2 X server provides. This is the only visual
+that works properly: as far as
+.BR xdpyinfo (1)
+is concerned, all of the 15-bit TrueColor visuals are identical, but some
+flicker like mad, and some have deeply weird artifacts (such as hidden
+surfaces that show through, as if depth worked backwards!)
+
+I suppose these other visuals must be tied to some arcane hardware feature...
+If anyone would care to explain it to me, that would be great.
+
+Your mileage, therefore, may vary dramatically.
+.TP 8
+.B MesaGL and Voodoo Cards
+If you have a 3Dfx/Voodoo card, the default settings for xscreensaver will
+run the GL-based graphics demos in such a way that they will not take
+advantage of the 3D acceleration hardware. The solution is to change
+the \fBprograms\fP entries for the GL hacks from this:
+.EX
+ gears -root \\n\\
+.EE
+to this:
+.EX
+ MESA_GLX_FX=fullscreen gears \\n\\
+.EE
+That is, make sure that \fB$MESA_GLX_FX\fP is set to \fIfullscreen\fP, and
+don't tell the program to draw on the root window. This may seem strange,
+but the setup used by Mesa and these kinds of cards \fIis\fP strange!
+
+For those who don't know, these cards work by sitting between your normal
+video card and the monitor, and seizing control of the monitor when it's
+time to do 3D. But this means that accelerated 3D only happens in full-screen
+mode (you can't do it in a window, and you can't see the output of 3D and 2D
+programs simultaniously), and that 3D will probably drive your monitor at a
+lower resolution, as well. It's bizarre.
+.TP 8
+.B Extensions
+If you are not making use of one of the server extensions (\fBXIDLE\fP,
+\fBSGI SCREEN_SAVER\fP, or \fBMIT-SCREEN-SAVER\fP), then it is possible, in
+rare situations, for \fIxscreensaver\fP to interfere with event propagation
+and make another X program malfunction. For this to occur, that other
+application would need to \fInot\fP select \fBKeyPress\fP events on its
+non-leaf windows within the first 30 seconds of their existence, but then
+select for them later. In this case, that client \fImight\fP fail to receive
+those events. This isn't very likely, since programs generally select a
+constant set of events immediately after creating their windows and then
+don't change them, but this is the reason that it's a good idea to install
+and use one of the server extensions instead, to work around this shortcoming
+in the X protocol.
+
+In all these years, I've not heard of even a single case of this happening,
+but it is theoretically possible, so I'm mentioning it for completeness...
+.TP 8