To print: troff -ms flash.txt

3 ======================================================================= || Colormap Compaction - A Technique for Reducing Colormap Flashing || ======================================================================= A. Introduction In some situations, it is beneficial to compact the xnews default colormap. This often leads to reduced colormap flashing. 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 colormap focus. 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. B. An Example of Colormap Flashing 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 flashing. 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. C. Why Does Colormap Flashing Happen? 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 low end of the colormap and pixel 255 is called the high end. 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: \(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. 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 color allocation. 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 shareable, 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. C. Types of Colormap Flashing 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 window-to-window 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 workspace colors. 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: \(bu A window manager (e.g olwm), 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. xsetroot), for the root background image. \(bu An oft-used application (e.g. filemgr). 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. D. Goals Colormap compaction 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. E. Instructions 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 xnews 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 cmap_compact(1). Prerequisites: \(bu Your \fL~/.xinitrc file should invoke a version of \fLopenwin-sys that has the following as its first line:

 cmap_compact init

The \fLopenwin-sys 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. \(bu Edit your \fL~/.openwin-menu file and insert the following lines into the Utilities menu after the "Save Workspace" menu entry: :

 "Save Colors" MENU
 "Save" DEFAULT $OPENWINHOME/bin/cmap_compact save
 "Discard" $OPENWINHOME/bin/cmap_compact discard
 "Save Colors" END 

If you do not have your own customized menu file, start with a copy of \fL$OPENWINHOME/lib/openwin-menu placed in your home directory, renamed to \fL.openwin-menu. Steps: 1. Run the server with the openwin(1) script. Be sure at this time to configure the server for all of the screens you want to compact colors for. openwin will (typically) execute ~/.openwin-init, which will in turn bring up your initial tools and programs. 2. If you use a program which loads a root background image (such as xsetroot(1)), make sure you run this program. Do this for every screen. 3. Use the Workspace Properties sheet to select your desired window border and/or root window background colors. This property is available by selecting the Properties entry of the root menu. Do this for every screen. 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. 5. At this point, the only colors which are in the default colormap should belong to the displayed programs. Go into the Utilities submenu of the root menu of any screen and select the Save Colors entry. All sharable (read-only) colors in the default colormaps for all screens will be recorded and stored in the file ~/.owcolors. Note: private (read-write) colors used by any of these applications will be ignored and will not be saved. 6. Exit the window system. 7. Reenter the window system by rerunning openwin. When you reenter the window system, the colors that have been stored in ~/.owcolors 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 Discard entry of the Save Colors 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. F. What if Colormap Flashing isn't Reduced? 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: \(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. \(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 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: \(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 staticvis). \(bu You should discard the saved workspace colors and reconfigure whenever you change the device modifiers (\fLstaticvis, \fLgrayvis or \fLdefdepth) used on the server command line. \(bu You should discard the saved colors and reconfigure whenever you remove a screen from your configuration. \(bu Colormap compaction does not preclude other means of inter-application color sharing which programmers may want to use. For example, X11 Standard Colormap properties 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. G. Summary 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.