Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.csd.uwm.edu!bionet!agate!garnet.berkeley.edu!csvsj
From: csvsj@garnet.berkeley.edu (Steve Jacobson)
Newsgroups: comp.windows.x
Subject: Window Managers, PseudoColor Displays, and "Technicolor"
Keywords: twm, dxwm
Message-ID: <1989Sep1.215106.11404@agate.uucp>
Date: 1 Sep 89 21:51:06 GMT
Sender: usenet@agate.uucp (USENET Administrator;;;;ZU44)
Reply-To: csvsj@garnet.berkeley.edu (Steve Jacobson)
Organization: University of California, Berkeley
Lines: 51

There are a number of strategies for minimizing "technicolor" color map
switching when running concurrent applications that require individual
color maps. There are many situations, however, where you must accept
that only one application will "look right" at a time.

At that point, the window manager becomes very important, since it will
allow the user to change color map focus.

The twm window manager changes colormap focus by tracking the mouse - wherever
the mouse is, that window's colormap is used. This behavior can often be
undesirable. For example, one window might have its own unique colormap, and
all the other windows use the root window colormap, and only use two entries
for foreground and background. If the window with the unique colormap is
careful about setting up its colormap, it can match those two entries so
the other windows "look right" when the unqie colormap window has the colormap
focus. But when another window has the focus, the unique colormap window
will go "technicolor", even though the non-unique colormap windows would look
ok if the unique colormap were still in place. Even when the user doesn't
want to shift keyboard and colormap focus to another window, mouse movements
that accidently move the mouse across the window border cause technicolor
flickering.

Worse things happen when an application with a unique color map uses multiple
windows. If the two windows are next to each other or overlap, and they both
use the same colormap, it seems reasonable to expect that the colormap focus
would not change as the pointer moves across the border from one window to
the other. But it looks like the twm created border uses the root window
colormap, so as the mouse crosses the border, there's a brief but very
disconcerting technicolor flash as the colormap shifts from the unique
colormap to the root colormap and back to the unique colormap.

Note that these comments about twm apply to the "unfocused" mode. When
"click to type" is used, it's hard to use applications with unique colormaps.
You have to iconify and deiconify windows to bypass the focus mechanism
to get colormaps to switch. However, when you can't change the colormap,
you don't have a flicker problem :-).

The DEC dxwm window manager handles this a little better. Colormap and
keyboard focus are linked together, and focus follows mouse clicks rather
than window exits and enters. This reduces technicolor flickering and the
user doesn't have to be so careful when moving the mouse. There are still
those situations where you might be happier with the colormap from one
window being in focus while you type in another.

It might be helpful to separate keyboard and colormap focus. For example, twm
might have another titlebar doodad to click on for "click to change colormap
focus." That way a user could optionally separate the focuses to minimize
flickering, minimize "wrong" colormaps, and provide flexibility. Color
flickering is disconcerting, but many users who don't like "click to type"
might not be happy about having to accept "click to type" to eliminate
flickering.