| Example 4-2 Using Individual Routines to
Define Graphics Characteristics |
GC gc;
.
.
.
static void doButtonPress(eventP)
XEvent *eventP;
{
(1) char dash_list[] = {20,5,10};
x1 = y1 = 100;
x2 = y2 = 550;
XSetBackground(dpy, gc, doDefineColor(4));
(2) XSetLineAttributes(dpy, gc, 0, LineDoubleDash, 0, 0);
(3) XSetDashes(dpy, gc, 0, dash_list, 3);
XDrawLine(dpy, win, gc, x1, y1, x2, y2);
}
|
- The dash_list variable defines the
length of odd and even dashes. The first and third elements of the
initialization list specify even dashes; the second element specifies
odd dashes.
- The SET LINE ATTRIBUTES routine enables the
client to define line width, style, cap style, and join style in one
call.
The SET LINE ATTRIBUTES routine has the following format:
XSetLineAttributes(display, gc_id, line_width, line_style, cap_style,
join_style)
|
The zero cap_style argument specifies the default
cap style.
- If using the CREATE GC routine to set line
dashes, odd and even dashes must have equal length. The SET DASHES
routine enables the client to define dashes of varying length. The SET
DASHES routine has the following format:
XSetDashes(display, gc_id, dash_offset, dash_list,
dash_list_len)
|
The dash_list_len argument specifies the length of
the dash list.
Figure 4-11 Line Defined Using GC Routines
4.4 Copying, Changing, and Freeing Graphics Contexts
In addition to defining a graphics context, clients can copy defined
characteristics from one GC data structure into another. To copy a GC
data structure, use COPY GC. The COPY GC routine has the following
format:
XCopyGC(display, src_gc_id, gc_mask, dst_gc_id)
|
The gc_mask argument selects values to be copied from
the source graphics context (src_gc_id). Use the
method described in Section 4.2 for assigning values to a GRAPHICS
CONTEXT.
The dst_gc_id argument specifies the new graphics
context into which the server copies values.
After creating a graphics context structure, change values as needed
using CHANGE GC. The following code fragment, which alters the values
of the line drawn by Example 4-1, illustrates changing a graphics
context structure:
.
.
.
xgcv.line_width = 10;
xgcv.line_style = LineSolid;
XChangeGC(dpy,gc,GCLineWidth | GCLineStyle,&xgcv);
.
.
.
|
The previous example illustrates defining a new line style and width,
and changing the graphics context to reflect the new values.
4.5 Using Graphics Characteristics Efficiently
The server must revalidate a graphics context whenever a client
redefines it. Causing the server to revalidate a graphics context
unnecessarily can seriously degrade performance.
The server revalidates a graphics context when one of the following
conditions occurs:
- A client associates the graphics context with a different window.
- The graphics context clip list changes. Changes in the clip list
can happen either when a client changes the graphics context clip
origin or when the server modifies the clip list in response to
overlapping windows.
- Any member of the graphics context changes.
To minimize revalidating the graphics context, submit as a group the
requests to the server that identify the same window and graphics
context. Grouping requests enables the server to revalidate the
graphics context once instead of many times.
When it is necessary to change the value of graphics context members
frequently, creating a new graphics context is more efficient than
redefining an existing one, provided the client creates no more than 50
graphics contexts.
Chapter 5
Using Color
Color is one of many attributes that clients can define when creating a
window or a graphics object. Depending on display hardware, clients can
define color as black or white, as shades of gray, or as a spectrum of
hues. Section 5.2 describes color definition in detail.
Xlib offers clients the choice of either sharing colors with other
clients or, when hardware supports it, allocating colors for exclusive
use.
A client that does not have to change colors can share them with other
clients. By sharing colors, the client saves color resources.
When a client needs to change colors, the client must allocate them for
its exclusive use. For example, the client might indicate the flow
through a pipeline by changing colors, rather than redrawing the entire
pipeline schematic. In this case, the client would allocate for
exclusive use colors that represent pipeline flow.
This chapter introduces color management using Xlib and describes how
to share
and allocate color resources. The chapter includes the following topics:
- Color fundamentals---A description of pixels and planes, color
indices, cells, and maps
- Matching color requirements to display types---How display types
affect color presentation
- Sharing color resources---How to share color resources with other
clients
- Allocating colors for exclusive use---How to reserve colors for a
single client
- Querying color resources---How to return values of color map entries
- Freeing color resources---How to release color resources
The concepts presented in this chapter apply to managing the color of
both windows and graphic objects.
5.1 Pixels and Color Maps
The color of a window or graphics object depends on the values of
pixels that constitute it. The number of bits associated with each
pixel determines the number of possible pixel values. On a monochrome
screen, one bit corresponds to each pixel. The number of possible pixel
values is 2. Pixels are either zero or one, black or white.
On a monochrome screen, all bits that define an image reside on one
plane. A plane is an allocation of
memory with a one-to-one correspondence between bits and pixels. The
number of planes is the depth of the screen.
The depth of intensity of color screens is greater than one. More than
one bit defines the value of a pixel. Each bit associated with the
pixel resides on a different plane.
The number of possible pixel values increases as depth increases. For
example, if the screen has a depth of four planes, the value of each
pixel comprises four bits. Clients using a four-plane intensity display
can produce up to sixteen levels of brightness. Clients using a
four-plane color display can produce as many as sixteen colors. The
number of colors possible on any system is equal to 2n ,
where n is the number of planes.
Figure 5-1 illustrates the relationship between pixel values and
planes.
Figure 5-1 Pixel Values and Planes
Xlib uses color maps
to define the color of each pixel value. A color map contains a
collection of color cells, each of which defines the
color represented by a pixel value in terms of its red, green, and blue
(RGB) components.
Red, green, and blue components range
from zero (off) to 65535 (brightest) inclusively. By combining the RGB
components, many colors can be produced.
Each pixel value refers to a location in a color map or is an
index into a color map.
For example, the pixel value illustrated in Figure 5-1 indexes color
cell 11 in Figure 5-2.
Figure 5-2 Color Map, Cell, and Index
Most color workstations have a hardware color map that translates pixel
values into colors for the entire workstation screen. When the color
definitions from a client's color map are stored in the hardware color
map, that color map is said to be installed. If a client's color map is
not installed, the client's
windows will display in the wrong color.
For example, an image processing program that requires 128 colors might
allocate and store a color map of these
values. To alter some colors, another client may invoke a color palette
program that chooses and mixes colors. The color palette program itself
requires a color map, which the program allocates and installs.
Because both programs have allocated different color maps, undesirable
results can be produced. The color palette image may be incorrectly
displayed when the image processing program runs. The incorrect display
results because only the image processing color map is installed.
Conversely, when the color palette program runs, the image processing
program may be incorrectly displayed because only the color palette
color map is installed.
Xlib reduces the problem of contending for color resources in two
ways:
- Xlib provides a default color map to which all clients have access.
- Clients can allocate either color cells for exclusive use or
colors for shared use from the default color map.
By sharing colors, a client can use the same color cells as other
clients. This method conserves space in the default color map.
In cases where the client cannot use the default color map and must use
a new color map, Xlib creates virtual color maps.
The use of virtual color maps is analogous to the use of virtual memory
in a multiprogramming environment where many processes must access
physical memory. When concurrent processes collectively require more
color map entries than exist in the hardware color map, the color
values are swapped in and out of the hardware color map. However,
swapping virtual color maps in and out of the hardware color map causes
contention for color resources. Therefore, the client should avoid
creating color maps whenever possible.
5.1.1 Installing Color Maps
The process of loading or unloading color values of the virtual color
map into the hardware lookup table occurs when a client calls the
INSTALL COLORMAP or UNINSTALL COLORMAP routine. Typically, the
privilege to install or to remove color maps is restricted to the
window manager. The window manager installs a color map when a window
is given focus. The user gives a window focus by clicking on it with
the mouse. The window manager then installs the color map for that
window.
On a system with a single hardware color map, only one window can have
color map focus
at a time. Giving the focus to a new window will cause the previous
window that had the focus to display in the wrong color.
Some systems provide multiple color maps in hardware. Multiple windows
can have color map focus simultaneously. Each window, however, must be
clicked on to install the correct color map and to get the correct
colors.
Applications that have a window manager running should not make direct
calls to install color maps. The window manager may reinstall different
color maps if the client attempts to install a private color map.
However, on a system with
multiple color maps, the window manager will not remove the private
color map. Thus, the client will display in correct colors without
getting color map focus.
Applications that require subwindows to have color maps separate from
the top-level window can use the SET WM COLORMAP WINDOWS routine. This
routine provides a hint to the window manager to install the specified
color map. Normally, window managers install color maps only for the
top-level window. Some applications are designed to run without a
window manager. In this case, the application must issue requests to
install its own color map.
5.2 Matching Color Requirements to Display Types
The basic philosophy, when using color, is to determine the color needs
of the client and then to determine how the system can best support
those needs.
This section defines the different visual display types available and
describes methods to choose the appropriate type for the client.
5.2.1 Visual Types
Each screen has a list of visual types associated with
it. The visual type identifies the characteristics of the screen, such
as color or monochrome capability. Visual types partially determine the
appearance of color on the screen and determine how a client can
manipulate color maps for a specified screen.
Color maps can be manipulated in a variety of ways on some hardware, in
a limited way on other hardware, and not at all on yet other hardware.
For example, a screen may be able to display a full range of colors or
a range of grays only, depending on its visual type.
VMS DECwindows defines the following visual types:
- Pseudocolor
- Gray scale
- Direct color
- True color
- Static gray
- Static color
Pseudocolor is a full-color device. A pixel value
indexes a color map composed of red, green, and blue definitions. Each
definition in the color map stores the red, green, and blue component
values for one color. The color index refers directly to a single entry
in the color map. RGB values can be changed dynamically if a pixel has
been allocated for exclusive use. Pseudocolor is the default visual
type on Digital 4-plane and 8-plane systems.
In Figure 5-3, the pseudocolor illustration shows a pixel value of 2
(00000010 in binary) that indexes entry 2 in the color map.
Gray scale is a black and white device. Gray scale is
the same as pseudocolor except that a pixel value indexes a color map
that produces shades of gray only. The gray shades are defined in a
color map with each definition having just one component that defines
the level of the white intensity.
Refer to Figure 5-3 for an illustration of the gray scale visual
type.
Direct color is a full-color device. Both the pixel
value and the color map are separated into three independent parts, one
each for red, green, and blue. The red part of the pixel indexes the
red color map, the green indexes the green color map, and the blue
indexes the blue color map. A complete color definition comprises the
three components in each color map. RGB values can be changed
dynamically if a pixel has been allocated for exclusive use.
In Figure 5-3, the direct color illustration shows that a pixel
value of 90 (01011010 in binary) is separated into three values by
using color masks, which are defined in the visual info data structure.
(Refer to Section 5.2.3 for information about the visual info data
structure.) Each color mask indicates which bits of the pixel value
reference which color map. Each value is then used to index one of the
three structures. In this case, entry 2 is indexed in the red color
map, entry 6 in the green color map, and entry 2 in the blue color map.
True color is a full-color device. True color is the
same as direct color except that the color map has predefined read-only
RGB values in ascending order. True color is the default visual type on
a Digital 24-plane system.
Refer to Figure 5-3 for an illustration of the true color visual
type.
Static gray is a black and white device. Static gray
is the same as gray scale except that the values in the color map are
read-only. Static gray with a two-entry color map can be thought of as
monochrome.
Refer to Figure 5-3 for an illustration of the static gray visual
type.
Static color is a full-color device and is the same as
pseudocolor except that the color map has predefined, read-only,
server-dependent values in an undefined, server-dependent order.
Figure 5-3 Visual Types and Color Map Characteristics
5.2.2 Determining the Default Visual Type
Before defining colors, use the following method to determine the
default visual type of a screen:
- Use the DEFAULT VISUAL OF SCREEN routine to determine the
identifier of the visual.
Xlib returns the identifier to a visual data structure.
- Refer to the class member of the data structure to determine the
visual type.
The following example illustrates one method to determine the default
visual type of a screen:
.
.
.
if ((XDefaultVisualOfScreen(screen))->class == TrueColor
|| (XDefaultVisualOfScreen(screen))->class ==
PseudoColor
|| (XDefaultVisualOfScreen(screen))->class ==
DirectColor
|| (XDefaultVisualOfScreen(screen))->class ==
StaticColor)
.
.
.
|
