+window managers don't have this problem. The race condition exists
+because X (really, ICCCM) does not provide a way for an OverrideRedirect
+window to have its own colormap, short of grabbing the server (which is
+neither a good idea, nor really possible with the current design.) What
+happens is that, as soon as xscreensaver installs its colormap, \fBtwm\fP
+responds to the resultant \fBColormapNotify\fP event by re-installing the
+default colormap. Apparently, \fBtwm\fP doesn't \fIalways\fP do this; it
+seems to do it regularly if the screensaver is activated from a menu item,
+but seems to not do it if the screensaver comes on of its own volition, or
+is activated from another console.
+.RS 8
+.TP 4
+.B Attention, window manager authors!
+You should only call
+.BR XInstallColormap (3)
+in response to user events. That is, it is appropriate to install a colormap
+in response to \fBFocusIn\fP, \fBFocusOut\fP, \fBEnterNotify\fP,
+and \fBLeaveNotify\fP events; but it is not appropriate to call it in
+response to \fBColormapNotify\fP events. If you install colormaps in
+response to \fIapplication\fP actions as well as in response to \fIuser\fP
+actions, then you create the situation where it is impossible for
+override-redirect applications (such as xscreensaver) to display their
+windows in the proper colors.
+.RE
+.TP 8
+.B Colormap lossage: XV, XAnim, XEarth
+Some programs don't operate properly on visuals other than the default one,
+or with colormaps other than the default one. See the discussion of the
+magic "default-n" visual name in the description of the \fBprograms\fP
+resource in the \fIConfiguration\fP section. When programs only work with
+the default colormap, you need to use a syntax like this:
+.EX
+ default-n: xv -root image-1.gif -quit \\n\\
+ default-n: xearth -nostars -wait 0 \\n\\
+.EE
+It would also work to turn off the \fBinstallColormap\fP option altogether,
+but that would deny extra colors to those programs that \fIcan\fP take
+advantage of them.
+.TP 8
+.B Machine Load
+Although this program ``nices'' the subprocesses that it starts,
+graphics-intensive subprograms can still overload the machine by causing
+the X server process itself (which is not ``niced'') to consume many
+cycles. Care has been taken in all the modules shipped with xscreensaver
+to sleep periodically, and not run full tilt, so as not to cause
+appreciable load.
+
+However, if you are running the OpenGL-based screen savers on a machine
+that does not have a video card with 3D acceleration, they \fIwill\fP
+make your machine slow, despite
+.BR nice (1).
+
+Your options are: don't use the OpenGL display modes; or, collect the
+spare change hidden under the cushions of your couch, and use it to
+buy a video card manufactured after 1998. (It doesn't even need to be
+\fIfast\fP 3D hardware: the problem will be fixed if there is any
+3D hardware \fIat all.\fP)
+.TP 8
+.B XFree86's Magic Keystrokes
+The XFree86 X server traps certain magic keystrokes before client programs ever
+see them. Two that are of note are Ctrl+Alt+Backspace, which causes
+the X server to exit; and Ctrl+Alt+F\fIn\fP, which switches virtual consoles.
+The X server will respond to these keystrokes even if xscreensaver has the
+screen locked. Depending on your setup, you might consider this a problem.
+
+Unfortunately, there is no way for xscreensaver itself to override the
+interpretation of these keys. If you want to disable Ctrl+Alt+Backspace
+globally, you need to set the \fIDontZap\fP flag in
+your \fI/etc/X11/XF86Config\fP file. To globally disable VT switching,
+you can set the \fIDontVTSwitch\fP flag. See the
+.BR XF86Config (5)
+manual for details.
+.TP 8
+.B MIT Extension and Fading
+The \fBMIT-SCREEN-SAVER\fP extension is junk. Don't use it.
+
+When using the \fBMIT-SCREEN-SAVER\fP extension in conjunction with
+the \fBfade\fP option, you'll notice an unattractive flicker just before
+the fade begins. This is because the server maps a black window just before
+it tells the \fIxscreensaver\fP process to activate. The \fIxscreensaver\fP
+process immediately unmaps that window, but this results in a flicker. I
+haven't figured a way to get around this; it seems to be a fundamental
+property of the (mis-) design of this server extension.
+
+It sure would be nice if someone would implement the \fBSGI SCREEN_SAVER\fP
+extension in XFree86; it's dead simple, and works far better than the
+over-engineered and broken \fBMIT-SCREEN-SAVER\fP extension.
+.TP 8
+.B Keyboard LEDs
+If \fIprocInterrupts\fP is on (which is the default on Linux systems) and
+you're using some program that toggles the state of your keyboard LEDs,
+xscreensaver won't work right: turning those LEDs on or off causes a
+keyboard interrupt, which xscreensaver will interpret as user activity.
+So if you're using such a program, set the \fIprocInterrupts\fP resource
+to False.
+.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...
+.SH ENVIRONMENT