3.1 Visual Types
On some display hardware,
it may be possible to deal with color resources in more than one way.
For example, you may be able to deal with a screen of either 12-bit depth
with arbitrary mapping of pixel to color (pseudo-color) or 24-bit depth
with 8 bits of the pixel dedicated to each of red, green, and blue.
These different ways of dealing with the visual aspects of the screen
are called visuals.
For each screen of the display, there may be a list of valid visual types
supported at different depths of the screen.
Because default windows and visual types are defined for each screen,
most simple applications need not deal with this complexity.
Xlib provides macros and functions that return the default root window,
the default depth of the default root window, and the default visual type
(see "
Display Macros" and "
Determining the Appropriate Visual Type").
Xlib uses an opaque
Visual
structure that contains information about the possible color mapping.
The visual utility functions (see "Determining the Appropriate Visual Type") use an
XVisualInfo
structure to return this information to an application.
The members of this structure pertinent to this discussion are class, red_mask,
green_mask, blue_mask, bits_per_rgb, and colormap_size.
The class member specifies one of the possible visual classes of the screen
and can be
StaticGray,
StaticColor,
TrueColor,
GrayScale,
PseudoColor,
or
DirectColor.
The following concepts may serve to make the explanation of
visual types clearer.
The screen can be color or grayscale,
can have a colormap that is writable or read-only,
and can also have a colormap whose indices are decomposed into separate
RGB pieces, provided one is not on a grayscale screen.
This leads to the following diagram:
| | Color | Gray-scale
|
| | R/O | R/W | R/O | R/W
|
| Undecomposed Colormap | Static Color | Pseudo Color | Static Gray | Gray Scale
|
| Decomposed Colormap | True Color | Direct Color |
|
Conceptually,
as each pixel is read out of video memory for display on the screen,
it goes through a look-up stage by indexing into a colormap.
Colormaps can be manipulated arbitrarily on some hardware,
in limited ways on other hardware, and not at all on other hardware.
The visual types affect the colormap and
the RGB values in the following ways:
- For
PseudoColor,
a pixel value indexes a colormap to produce
independent RGB values, and the RGB values can be changed dynamically.
- GrayScale
is treated the same way as
PseudoColor
except that the primary that drives the screen is undefined.
Thus, the client should always store the
same value for red, green, and blue in the colormaps.
- For
DirectColor,
a pixel value is decomposed into separate RGB subfields, and each
subfield separately indexes the colormap for the corresponding value.
The RGB values can be changed dynamically.
- TrueColor
is treated the same way as
DirectColor
except that the colormap has predefined, read-only RGB values.
These RGB values are server-dependent but provide linear or near-linear
ramps in each primary.
- StaticColor
is treated the same way as
PseudoColor
except that the colormap has predefined,
read-only, server-dependent RGB values.
- StaticGray
is treated the same way as
StaticColor
except that the RGB values are equal for any single pixel
value, thus resulting in shades of gray.
StaticGray
with a two-entry
colormap can be thought of as monochrome.
The red_mask, green_mask, and blue_mask members are only defined for
DirectColor
and
TrueColor.
Each has one contiguous set of bits with no
intersections.
The bits_per_rgb member specifies the log base 2 of the
number of distinct color values (individually) of red, green, and blue.
Actual RGB values are unsigned 16-bit numbers.
The colormap_size member defines the number of available colormap entries
in a newly created colormap.
For
DirectColor
and
TrueColor,
this is the size of an individual pixel subfield.
To obtain the visual ID from a
Visual ,
use
XVisualIDFromVisual().
Christophe Tronche, [email protected]
