.\" 

.\" To print: troff -ms flash.txt

.\" 

.ft B

.ce 3

=======================================================================

||  Colormap Compaction - A Technique for Reducing Colormap Flashing ||

=======================================================================

.ft P

\fBA. Introduction\fP

In some situations, it is beneficial to \fIcompact\fP the \fBxnews\fP default

colormap.  This often leads to reduced \fIcolormap flashing\fP.  Colormap

flashing occurs when colors in two different software colormaps conflict

with each other.  Since only one software colormap can be loaded into the

hardware at a time, for a given pixel value you will see the color

which is in one colormap or the other.  Which color you see depends

on the window into which you assign the \fIcolormap focus\fP.  Typically,

the focus is assigned to a window by moving the pointer into it.

This material applies only to color devices which have a single

hardware color LUT, such as GX.  It does not apply to monochrome screens.   

The technique describe herein may be used on a device which

provides multiple hardware color LUTs, such as GS or GT, but it

is less valuable in this configuration, because the benefit will

probably not be as pronounced as it can be on a single hardware

color LUT device.

\fBB. An Example of Colormap Flashing\fP

Let us suppose we have two windows, window A and window B.

Window A is attached to software colormap A; window B is attached to 

software colormap B.  When you move the pointer into window A, colormap A 

will be loaded into the hardware colormap.  Likewise, when you move

the pointer into window B, colormap B will be loaded.  

Let's say the pixel value 5 is drawn somewhere on the screen.  Let's also

suppose that the color value for pixel 5 in colormap A is Red and

the color value for pixel 5 in colormap B is Blue.  When the pointer is

in window A, all pixels of value 5 will be displayed as Red, no matter where

they are on the screen.  When the pointer is in window B, these same pixels

will be displayed as Blue.  

In OpenWindows, a software colormap will only displace the other in places where they

each have allocated colors.   In places where no colors 

have been allocated, the contents of the hardware will remain set to the previous values.

Thus, the colors of two software colormaps can exist harmoniously together in the 

hardware colormap only if their allocated colormap entries do not intersect.

(Readers familiar with Sunview should note that this style of colormap management 

is very different than the named colormap segment scheme used by Sunview.)

Moving the pointer rapidly back and forth between windows A and B causes

the pixels with value 5 on the screen to blink between Red and Blue.

This is why this effect is called colormap \fIflashing\fP.

The rest of this discussion will assume a basic level of familiarity

with X11 colormap concepts.  Users should refer to O'Reilley Volume 1

Chapter 7 "Color" for more information.

\fBC. Why Does Colormap Flashing Happen?\fP

The previous section discussed the effects and symptoms of colormap

flashing.  But the fundamental question remains: what causes the

colors in the two colormaps to coincide and conflict?

For the purposes of the following discussion, pixel 0 is called the 

\fIlow end\fP of the colormap and pixel 255 is called the \fIhigh end\fP.

Because, for a typical device, a maximum of 256 distinct colors can be displayed 

on a screen at once, colors are a very scarce resource.  The X11R4 standard provides

some mechanisms for sharing colors between client programs, thus

reducing the chance of colormap flashing.  For example, two different

applications may share the same pixel value, and therefore the same color,

in a single colormap.  Usually, a client program has to explicitly try

to share colors with other clients.  Some situations in which such

attempts break down are:

.in +0.5i

\(bu   All of the clients which are running collectively demand more 

than 256 distinct colors.

\(bu   One or more clients make no attempt at all to share colors

with other applications.

\(bu   One or more clients use read-write (modifiable) colors, which

cannot be shared.

.in -0.5i

There are several techniques X11 client programmers can use to share 

colors.  Most of them entail the implementation of additional code

in the program.  What we seek to present in this document,

is a generic technique that any OpenWindows user can take advantage of,

regardless of whether a particular program contains explicit code

which tries to reduce colormap flashing.

Client programs ask the xnews server to grant them pixels to use by telling

the server what colors they desire.  The server figures out where to 

put the colors in the colormap and then tells the clients which pixels

have been assigned to them.  This process is called \fIcolor allocation\fP.

Unless client programs do something out of the ordinary, color allocations

tend to gravitate toward the low end of a colormap.  This is because the 

server always gives a client the lowest unused pixel when allocating a

new color. 

The default colormap is a colormap which all clients know about and

can use.  By default, when a window is created, the default colormap is 

attached it. If a client allocates a color in a colormap and indicates it to be

\fIshareable\fP, other clients allocating the same color value are

able to share these colors.  More sharing of colors means less color

conflicts and less colormap flashing.  The default colormap, therefore,

is the preferred colormap to use if you want to share colors.  Sometimes

a program cannot use the default colormap and must allocate its

colors in an alternate colormap.  This increases the chances of flashing

between the colors in these two different colormaps.  Sometimes a program wants 

to use the default colormap, but cannot because it is full.  The program is then 

forced to use an alternate colormap.  This, again, increases the chance of flashing.

To summarize, client applications would like to use the default colormap if 

possible, but sometimes they need to or are forced to use an alternate 

colormap.   The only way to prevent colormap flashing between two separate 

colormaps is to make them disjoint--to ensure their color allocations not 

intersect.

\fBC. Types of Colormap Flashing\fP

Some kinds of colormap flashing are worse than others.  For example,

an MCAD application which flashes against a spreadsheet program

is unpleasant, but since the flashing is usually confined to specific

window areas, it can often be tolerated as a reality of limited

hardware.  However, if the same MCAD application flashes against

the root window background or the frame border colors, the effect

is usually very pronounced.  This is very disconcerting and 

disorienting for the user.

It is specifically this latter type of colormap flashing that the

colormap compaction attempts to solve.  Other techniques for dealing 

with the former type of flashing exist, but they usually require

programming changes and, therefore, are not something the end-user 

can typically take advantage of without having specially-modified software.  

We will therefore not deal further with this \fIwindow-to-window\fP type of

colormap flashing.  What we 

will proceed to address is the problem of the flashing of windows against 

a group of colors called the \fIworkspace colors\fP.

The workspace colors are colors which are in some way important

or pervasive in a user's workspace.  They may be colors which

cover a large area on the screen or they may be colors appear

in frequently used applications.  Some examples of applications

which might utilize workspace colors are:

.in +0.5i

\(bu   A window manager (e.g \fBolwm\fP), for the root background, window borders, and menus.

\(bu   A toolkit (e.g. XView), for window decorations and controls.

\(bu   A root image loader (e.g. \fBxsetroot\fP), for the root background image.

\(bu   An oft-used application (e.g. \fBfilemgr\fP).

.in -0.5i

Which colors should be designated as workspace colors is left

up to the user.  The only criteria for a workspace color is that it 

be a read-only (sharable) color and that it be allocated in the default 

colormap of a screen.

To summarize, the workspace colors are the colors the user has deemed

to be important and with which he or she would prefer not to have

any colormap flashing.

\fBD. Goals\fP

\fIColormap compaction\fP takes advantage of the identification

of the colors of special applications and the low-end clustering effect of

typical applications.  It takes advantage of these

by shoving the workspace colors up to the top of the colormap.

In this position, there is a reduced chance of the colors flashing

flashing with other applications.

It is important that it be easy to identify the workspace colors.

Detailed knowledge of how X11 colormaps work should not be required.

Nor should any programming ability be required.  Lastly, we

don't want to rely on the availability of specially adapted programs;

the technique should work with any arbitrary program which conforms

to the X11 standard protocol.

All of these considerations lead us to the method which is described

in the following section.

\fBE. Instructions\fP

The preceding material has been presented to give you a overall sense

what the problem is and the general method of solution.  This section

will show you how to apply this method in the OpenWindows environment.

In a nutshell, to reduce or prevent colormap flashing, you need to run the 

\fBxnews\fP server, perform some configuration steps, and then exit the server.

The next time you run the server, the workspace colors  you designate

will be put up at the high end of the default colormap.

For additional details on this process, refer to \fBcmap_compact\fP(1).

Prerequisites:

.in +0.5i

.ti -1.5

\(bu   Your \fL~/.xinitrc\fP file should invoke a version of 

\fLopenwin-sys\fP that has the following as its first line:

.in +0.5i

.ft L

.nf

.na

	cmap_compact init

.ft P

.fi

.ad

.in -0.5i

The \fLopenwin-sys\fP shipped with OpenWindows 3.0 contains this

line.   If you use some other file, be sure to add this line.

The process should never be backgrounded.

.ti -1.5

\(bu   Edit your \fL~/.openwin-menu\fP file and insert the following lines into the \fIUtilities\fP menu

after the "Save Workspace" menu entry:

:

.in +0.5i

.ft L

.nf

.na

    "Save Colors" MENU

	"Save" DEFAULT  $OPENWINHOME/bin/cmap_compact save

	"Discard"       $OPENWINHOME/bin/cmap_compact discard

    "Save Colors" END 

.ft P

.fi

.ad

.in -0.5i

If you do not have your own customized menu file, start with a copy

of \fL$OPENWINHOME/lib/openwin-menu\fP placed in your home directory, renamed

to \fL.openwin-menu.\fP

.in -0.5i

Steps:

.in 0.5i

.ti -2.0

1.   Run the server with the \fBopenwin\fP(1) script.  Be sure at this

time to configure the server for all of the screens you want to 

compact colors for.  \fBopenwin\fP will (typically) execute 

\fI~/.openwin-init\fP, which will in turn bring up your initial

tools and programs.

.ti -2.0

2.   If you use a program which loads a root background image (such as

\fBxsetroot\fP(1)), make sure you run this program.  Do this for 

every screen.

.ti -2.0

3.   Use the \fIWorkspace Properties\fP sheet to select your desired

window border and/or root window background colors.  This property

is available by selecting the \fIProperties\fP entry of the

root menu.  Do this for every screen.

.ti -2.0

4.   Choose the applications whose colors you want to designate as

workspace colors.  You do this by either quitting undesired

applications which are on the screen or by running desired 

applications which are not yet on the screen.  Do this for

every screen.

.ti -2.0

5.   At this point, the only colors which are in the default colormap

should belong to the displayed programs.  Go into the 

\fIUtilities\fP submenu of the root menu of any screen and select the

\fISave Colors\fP entry.  All sharable (read-only)

colors in the default colormaps for all screens will be recorded and stored in 

the file \fI~/.owcolors\fP.  Note: private (read-write) colors used 

by any of these applications will be ignored and will not

be saved.

.ti -2.0

6.   Exit the window system.

.ti -2.0

7.   Reenter the window system by rerunning \fIopenwin\fP.

.in -0.5i

When you reenter the window system, the colors that have

been stored in \fI~/.owcolors\fP are placed at the high

end of the default colormap.  Since this is done before

any of the other applications are started, when these

applications are finally started, they will find the colors

they want waiting for them at the high end and will use

them there.

Note: If you decide to change any of the workspace colors, you should

repeat steps 3-7.  Otherwise, you may end up with more colormap

flashing.

If, at any time, you wish to undo the effects of the colormap

compaction, select the \fIDiscard\fP entry of the \fISave Colors\fP

submenu.

As a side-effect of colormap compaction, the NeWS color cube in the 

StaticColor colormap gets shifted downward.  The cube is shifted down by 

the number of workspace colors you have saved (actually, the number 

of colors for the screen with the most colors).  This is done to avoid 

flashing between NeWS windows and the workspace colors.  Note: the base 

of the color cube is never shifted lower than pixel 0.

The black and white pixels which are pre-allocated in the default colormap

by the server are shifted up to the high end of the colormap.

In addition, XGL (version 2.0 and greater) will recognize that 

colormap compaction has been turned on and will adjust its 

color cube accordingly.   XGL usually allocates its color cube

at the high end of its colormap by default.   When colormap

compaction is turned on, XGL will allocate its color cube at

the low end of the colormap.

\fBF. What if Colormap Flashing isn't Reduced?\fP

Colormap compaction is a heuristic technique: it is not always effective

in reducing colormap flashing and, in some situations, may actually

increase colormap flashing.   The result of using colormap compaction

is highly dependent on the applications you use and the way that you

have configured color on your desktop.

Here are some example situations in which colormap compaction does

not succeed:

.in +0.5i

.ti -1.5

\(bu   If you are running a program which allocates

its colors at the high end of a non-default colormap on purpose,

this program will end up flashing more with the workspace colors.

.ti -1.5

\(bu   If you select a large amount of workspace colors, the 

NeWS color cube may be shifted down enough to start

flashing more with X11 applications allocating their

colors at the low end.  This may increase colormap flashing

between X11 and NeWS applications.

.in -0.5i

In general, the amount of colormap flashing reduction or 

increase afforded by colormap compaction is highly dependent

on the set of applications you run in your environment.

For many environments, colormap compaction will be useful.

But there are some environments for which it is not.

The best policy is to give it a try and see if it helps.

If it does not help, turn it off by selecting discard on

the "Save Colors" menu.

Some other things to be aware of:

.in +0.5i

.ti -1.5

\(bu   Colormap compaction has no effect for screens which

have the StaticColor colormap as the default (i.e. for

screens which have a device modifier of \fIstaticvis\fP).

.ti -1.5

\(bu   You should discard the saved workspace colors and 

reconfigure whenever you change the device modifiers

(\fLstaticvis\fP, \fLgrayvis\fP or \fLdefdepth\fP) used on 

the server command line.

.ti -1.5

\(bu   You should discard the saved colors and reconfigure whenever

you remove a screen from your configuration.

.ti -1.5

\(bu   Colormap compaction does not preclude other means of 

inter-application color sharing which programmers may

want to use.  For example, X11 \fIStandard Colormap

properties\fP can be used to promote sharing among imaging

applications that use lots of colors.  Application developers can

use these properties in conjunction with colormap 

compaction to achieve even less colormap flashing.

.in -0.5i

\fBG. Summary\fP

Compacting the default colormap is the process of selecting certain application

colors you would prefer not to flash and saving these

colors into a file.  When the window system is reentered, these colors

will end up at the high end of the default colormap, a preferred position

which often decreases colormap flashing.

This process may not always make sense for your situation.  Depending on the

applications you run, it may or may not help, but it probably will.  You

must also make sure you keep the configuration up-to-date to continue

to derive the maximum benefits.  If, after trying colormap compaction, colormap 

flashing on your desktop is not reduced, colormap compaction should be turned back off.