Integrated Color Graphics Device-Dependent Information

Supported Visuals

For color displays:

For grayscale displays, only one visual is supported:

Supported Environment Variables

The following environment variables are supported:

Colormaps and Colormap Management

Color Graphics devices have two hardware colormaps (color lookup tables), each with 256 entries. The X server controls the allocation and contents of these hardware colormaps.

The Default Colormap Management Scheme

Many applications use the default X11 colormap. A "technicolor" effect in the windows using the default colormap occurs when a non-default colormap is downloaded into the hardware colormap that had previously contained the default colormap.

Because so many applications use the default X11 colormap — including the window manager — and because Color Graphics devices have two hardware colormaps, the default behavior on this device is to dedicate one hardware colormap to always hold the default X11 colormap. The second hardware colormap is available to applications that use colormaps other than the default.

The default behavior can cause technicolor if two or more applications are using different, non-default colormaps. For example, Application A uses the default X11 colormap, Application B uses a different colormap, and Application C uses a third colormap. If applications A, B, and C are all executed simultaneously on a Model 712, application A would look correct. Either application B or C would have a technicolor effect — the application whose colormap was last downloaded into the hardware colormap would look correct.

Accessing HP Color Recovery Technology via Xlib

Color Recovery is a technique to generate a better picture by attempting to eliminate the graininess caused by dithering. Access to the Color Recovery capability is transparent when using a 3D graphics API such as Starbase, HP-PHIGS or PEX. If you are producing graphics using Xlib calls, your application must perform some of the necessary processing. At server startup (if Color Recovery is not disabled in the X*screens file), the following properties are defined and placed on the root window:

These properties are of type RGB_COLOR_MAP and carry pointers to structures of type XStandardColormap. They may be interrogated with calls to XGetRGBColormaps. The colormaps in the _HP_RGB_SMOOTH_TRUE_MAP and _HP_RGB_SMOOTH_PSEUDO_MAP structures identify colormaps which are created at server startup and are for use with the TrueColor and PseudoColor visuals, respectively. They are both initialized to contain the 3:3:2 ramp of 8-bit TrueColor. Neither of these colormaps can be modified, as they are read-only. The property _HP_RGB_SMOOTH_MAP_LIST is a list of colormaps that are associated with window visual IDs that support Color Recovery. When the XGetRGBColormaps routine searches through this list for a colormap with a visual ID that matches your window's visual ID and it finds one, your application knows that your visual supports Color Recovery, and uses that colormap for any Color Recovery window in your window's visual.

Note that the algorithm used for the Color Graphics device is slightly different from that used for the HCRX family of devices. If you do not wish for your application to have to do device-specific checks, HP recommends that you use the HCRX encoding algorithm for Color Recovery regardless of the device on which your application is executing. The results on the Color Graphics device will not be optimal, but will generally still be much better than a standard dither. If you are willing to do device-specific checks, the existence of either the _HP_RGB_SMOOTH_TRUE_MAP or _HP_RGB_SMOOTH_PSEUDO_MAP property will indicate the device is Color Graphics.

Color Recovery uses all 256 entries of one of the available colormaps. The color visual used by Color Recovery emulates the 24-bit TrueColor visual, thus, the colors red, green, and blue are typically declared as integers in the range from 0 to 255. Note that each window that uses Color Recovery will have the same colormap contents.

For Color Recovery to produce the best results, the emulated 24-bit TrueColor data is dithered as explained below.

A pixel to be dithered is sent to the routine provided in this example. Note that the values of the variables RedValue, GreenValue, and BlueValue are generated by an application. In this example, the color values are assumed to be in the range 0..255.

The given routine receives the color values and the X and Y window address (Xp and Yp) of the pixel. The X and Y address is used to access the dither tables. The values from the dither tables are added to the color values. After the dither addition, the resultant color values are quantized to three bits of red and green and two bits of blue. The quantized results are packed into an 8-bit unsigned char and then stored in the frame buffer. In the process of sending the contents of the frame buffer to the CRT, a special section in the hardware then converts the frame buffer's 8-bit data into a 24-bit TrueColor data for display.

Here is a routine that can be used to dither the 24-bit TrueColor data.

unsigned char dither_pixel_for_CR(RedValue, GreenValue, BlueValue, Xp, Yp)
int     RedValue, GreenValue, BlueValue, Xp, Yp;
{
    static short        dither_red[2][16] = {
      {-16,  4, -1, 11,-14,  6, -3,  9,-15,  5, -2, 10,-13,  7, -4,  8},
      { 15, -5,  0,-12, 13, -7,  2,-10, 14, -6,  1,-11, 12, -8,  3, -9}};
    static short        dither_green[2][16] = {
      { 11,-15,  7, -3,  8,-14,  4, -2, 10,-16,  6, -4,  9,-13,  5, -1},
      {-12, 14, -8,  2, -9, 13, -5,  1,-11, 15, -7,  3,-10, 12, -6,  0}};
    static short        dither_blue[2][16] = {
      { -3,  9,-13,  7, -1, 11,-15,  5, -4,  8,-14,  6, -2, 10,-16,  4},
      {  2,-10, 12, -8,  0,-12, 14, -6,  3, -9, 13, -7,  1,-11, 15, -5} };
    int                 red, green, blue;
    int                 x_dither_table, y_dither_table;
    unsigned char       pixel;
 
    /* Determine the dither table entries to use based on the pixel address */
    x_dither_table = Xp % 16;   /* X Pixel Address MOD 16 */
    y_dither_table = Yp % 2;    /* Y Pixel Address MOD 2 */
 
    /* Start with the initial values as supplied by the calling routine */
    red   = RedValue;
    green = GreenValue;
    blue  = BlueValue;
 
    /* Generate the red dither value */
    red += dither_red[y_dither_table][x_dither_table];
    /* Check for overflow or underflow on red value */
    if (red > 0xff) red = 0xff;
    if (red < 0x00) red = 0x00;
 
    /* Generate the green dither value */
    green += dither_green[y_dither_table][x_dither_table];
    /* Check for overflow or underflow on green value */
    if (green > 0xff) green = 0xff;
    if (green < 0x00) green = 0x00;
 
    /* Generate the blue dither value */
    blue += (dither_blue[y_dither_table][x_dither_table]<<1);
    /* Check for overflow or underflow on blue value */
    if (blue > 0xff) blue = 0xff;
    if (blue < 0x00) blue = 0x00;
 
    /* Generate the pixel value by "or"ing the values together */
    pixel = ((red &0xE0) | ((green &0xE0) >> 3) | ((blue &0xC0) >> 6));
    return(pixel);
}