A good source of detailed information about X Window color handling is the Xlib Programming Manual published by O'Reilly & Associates, Inc.
Microsoft Windows and X Windows each use a color table that is hardware-dependent, so the color tables vary from one display type to another. Both window systems also let applications provide their own color tables, and here is where color handling in the two systems differs markedly.
For some displays, Microsoft Windows uses a single color palette, one that cannot be changed. If an application requests a color that is not in the palette, Windows either uses the closest color it can find in the palette, or approximates the color by making a pattern composed of pixels of different colors. For example, a light yellow might be approximated using a checkerboard pattern of bright yellow and white. This is called dithering. Usually, if the color is for a line, Windows uses the closest color. If the color is for filling a shape, Windows dithers the color.
For other displays, Microsoft Windows uses a palette manager, which can change colors in the default palette. If an application requests a color that is not in the palette, and an unallocated color cell exists, the color is added to the palette. If there are no more unallocated color cells, Windows either matches the logical palette color to the closest color it can find in the default palette, or dithers it.
Because all windows running in Microsoft Windows use the default palette, Windows allocates colors for the active window first, to make sure its colors are correct. The inactive windows could potentially show some colors that are not exactly what the application requested. However, for the most part, colors in inactive windows are close to what is intended.
The X server has a default visual, the method used to handle color when an X application does not request a specific visual. The Wabi program uses the X server's default visual whenever possible.
On the most common types of color display, 8-bit or 8-plane, the usual default is a visual called PseudoColor, which is therefore the visual that the Wabi program uses most often.
Eight-plane displays generally have one hardware colormap, into which the X server loads a default colormap when it first starts up. The default X colormap is changeable, so X applications can change individual color cells in the default colormap to allocate colors they need.
X applications can also provide their own colormaps, called virtual colormaps, which are loaded into the hardware colormap. The X server can maintain more than one virtual colormap at the same time, but only one can be used in the hardware colormap at any given instant. This means that if the active application swaps in its own colormap, the windows of all other (inactive) applications must use this same colormap. As a consequence, the color cells assigned to pixels might now contain colors completely different from those intended, resulting in undesirable color schemes for the inactive windows.
As you change focus from one window to another, colors flash as each application's colormap is loaded and used by all running applications.
To minimize color flashing, only color-intensive X applications use virtual colormaps. The Wabi program is a color-intensive X application by virtue of the many color-intensive Windows applications it runs, so color flashing can be a problem. You can alleviate color flashing by controlling certain aspects of the Wabi colormap.
When the Wabi program starts, it uses the current default colormap as the starting point for creating a virtual colormap. First, the Wabi program changes some of the color cells in the default colormap to provide a range of colors needed for the Windows applications you may subsequently run. It allocates 49 colors -- seven shades of each of the seven solid colors (red, green, blue, cyan, magenta, yellow, and gray). In addition, it allocates 15 more colors -- five shades of each of the primary colors (red, green, and blue). Some of these additional reds, greens, and blues may be duplicates of the 49 shades of solid colors, so the total number of colors allocated may be something less than 64 colors. On an eight-plane display (which has 256 colors in its colormap), this leaves the majority of colors in the default colormap unchanged. Wabi then copies the changed default map into its own virtual colormap. Finally, the Wabi program frees half of the color cells it allocated in the default colormap so that they can be allocated by other X applications.
win.ini.
The Wabi program provides variables that influence how the Wabi colormap is created and how Wabi affects the default X colormap. One variable, Technicolor, affects Wabi on all display types. The other variables depend on Technicolor being set to 0, and apply only when Wabi is using the 8-bit PseudoColor visual. You set the variables in your win.ini file.
Technicolor VariableTechnicolor variable allows you to make a trade-off between color flashing, or "technicolor," and flexibility in allocating and changing colors in Microsoft Windows applications running in the Wabi program. If you want applications running in the Wabi program to be able to allocate all the colors they want, you can set Technicolor=1, and put up with color flashing in inactive X windows. If it does not matter if applications in Wabi get the exact colors they want, you can set Technicolor=0, and color flashing is minimized as Wabi tries to share colors with other X applications.
The default value is 0 (color flashing off), unless there is more than one hardware colormap for the display screen. If there is more than one hardware colormap, it is assumed one will be available for , and the value defaults to 1. This may sometimes cause color flashing on 24-bit displays using 8-bit PseudoColor.
When Technicolor=0, Wabi allocates colors from the default X colormap and then copies them to the Wabi colormap, as described in "The Wabi Colormap," in an attempt to share as many colors as possible.
When Technicolor=1, Wabi uses a standard X colormap as its colormap. This often causes color flashing on 8-bit displays and 24-bit displays when you switch between Wabi windows and other X windows.
If your X server has more than one hardware colormap, but the colormaps are normally already in use by other X applications when you start , you can set Technicolor to 0 to alleviate color flashing.
If your X server has one colormap, as is the case with most 8-bit displays, you may set Technicolor to 1 to give , and the Windows applications running under it, the most flexibility in allocating and changing color. If you need the color flexibility and find that color flashing is annoying, try maximizing the Wabi window when you use the Windows application. This prevents the mouse pointer from drifting into other X application windows and causing their colormaps to be swapped in.
Technicolor is set to 0. You can see if Wabi is using 8-bit PseudoColor by running the X program xwininfo, which should be present on most Linux systems with X windows.
In a Linux command line window, type the following command:
xwininfoand then select the Wabi window when prompted.
Look for the following lines:
Depth:8 Visual Class: PseudoColorIf you see these lines, you can use the variables in Table B-1 below.
If xwininfo is not available, use the xdpyinfo command. This displays information about your X server, including the visuals that are available.
In a Linux command line window, type the following command:
xdpyinfo | grep classIf you see the class PseudoColor, you can use the variables in Table B-1 below.
| Variable | Description |
PercentFree=n | When Technicolor=0, PercentFree specifies how much of the default X colormap Wabi should free up after allocating its colors. The range of acceptable values is 0 through 100, with a default of 50, which means Wabi frees 50% of the color cells. Setting Setting |
SolidColorCount=n | When Technicolor=0, this variable defines how many shades of each of the seven colors (red, green, blue, cyan, magenta, yellow, and gray) are allocated. A total of 7 shades x SolidColorCount colors are allocated. The range of acceptable values is 1 through 16, with a default of 7. Set this variable higher to let Wabi allocate more colors so that applications running under Wabi don't find it necessary to allocate new colors. Set this variable lower if most colors have already been Wabi defined by X applications before Wabi starts, or if you will be manually defining all your colors anyway (through a "paint" program, for example). |
RedCubeCount=nGreenCubeCount=nBlueCubeCount=n | When Technicolor=0, these three variables define the dimensions of the red, green, and blue components of the color cube. The color cube comprises the additional reds, greens, and blues that Wabi adds to its colormap. These variables allow you to alter the number of reds, greens, and blues, respectively, that will be used in the Wabi colormap. The range is 4 through 9, with a default of 5. You can adjust these variables if you find that Windows applications you run need more colors of a particular shade. These variables usually do not affect color flashing. |
An additional variable, UseRootWindow, may be useful if you find Wabi has problems drawing to your 24-bit display. UseRootWindow=n tells whether or not Wabi can draw to and read from the root window (the "background" window of the desktop). The default value is 1 (yes), unless the Wabi colormap and the default colormap are of different sizes, in which case the default is
0 (no).
Most users will never need to set UseRootWindow, and should not set it because it may cause problems, especially on 8-bit displays. You should only consider using it if you are using a 24-bit display and Wabi appears to be having problems drawing to the screen (windows and icons do not look right, for example).
If you are experiencing such problems, experiment with UseRootWindow to see if it alleviates them. If this does nothing, or makes the drawing worse, remove the variable entirely.
$HOME/wabi/windows/win.ini file and add them. None of the variables appear in win.ini as shipped in the Wabi program.
If you want the variables to affect your running of Wabi on any display you use, set the variables in the [ColorMap] section in win.ini. For example, if all displays you use are 8-bit, set the variables in the[ColorMap] section.
If you run Wabi on more than one display and you want the variables to affect Wabi only on a particular display, create a section whose title is the display name and set the variables in that section. For example, to apply the variables to Wabi only when you display it on the display jethro:0.0, create a section called [jethro:0.0].
The Wabi program reads the [ColorMap] section first, and then the [host:0.0] sections, so that variables set in [host:0.0] sections supercede variables set in the [ColorMap] section for the specified displays. If you set the same variables in both sections, the [host:0.0] variables are used for those displays. This may be helpful if you use multiple displays and one of them is 24-bit, for example. You could set variables specific to the 24-bit display by creating a [host:0.0] section, and set variables for all 8-bit displays in the [ColorMap] section.