RECORD /X$SET_WIN_ATTRIBUTES/ XSWDA
.
.
.
ATTR_MASK = X$M_CW_BORDER_PIXEL .OR. X$M_CW_BACK_PIXEL
(1) XSWDA.X$L_SWDA_BACKGROUND_PIXEL = X$BLACK_PIXEL_OF_SCREEN(SCREEN)
XSWDA.X$L_SWDA_BORDER_PIXEL = X$WHITE_PIXEL_OF_SCREEN(SCREEN)
(2) CALL X$CHANGE_WINDOW_ATTRIBUTES(DPY, WINDOW, ATTR_MASK, XSWA)
.
.
.
|
- Assign new values to a set window attributes data structure.
- Call CHANGE WINDOW ATTRIBUTES to change the
window attributes. The CHANGE WINDOWS attributes routine has the
following format:
X$CHANGE_WINDOW_ATTRIBUTES(display, window_id,
attributes_mask, attributes)
Specify the attributes to change with a bitwise inclusive OR of the relevant symbols listed in Table 3-3. The values argument passes the address of a set window attributes data structure.
3.10 Getting Information About Windows
Using Xlib information routines, clients can get information about the parent, children, and number of children in a window tree; window geometry; the root window in which the pointer is currently visible; and window attributes.
Table 3-19 lists and describes Xlib routines that return information about windows.
| Routine | Description |
|---|---|
| QUERY TREE | Returns information about the window tree |
| GET GEOMETRY | Returns information about the root window identifier, coordinates, width and height, border width, and depth |
| QUERY POINTER | Returns the root window that the pointer is currently on and the pointer coordinates relative to the root window origin |
| GET WINDOW ATTRIBUTES | Returns information from the window attributes data structure |
To get information about window attributes, use the GET WINDOW ATTRIBUTES routine. The client receives requested information in the window attributes data structure. See the X Window System for more information about the window attributes data structure.
Chapter 4
Defining Graphics Characteristics
After opening a display and creating a window, clients can draw lines and shapes, create cursors, and draw text. Creating a graphics object is a two-step process. Clients first define the characteristics of the graphics object and then create it. For example, before creating a line, a client first defines line width and style. After defining the characteristics, the client creates the line with the specified width and style.
This chapter describes how to define the graphics characteristics prior to creating them, including the following topics:
- The graphics context (GC)---A description of the graphics characteristics a client can define and the GC values data structure used to define them
- Defining graphics characteristics---How to define graphics characteristics using the CREATE GC routine
- Copying, changing, and freeing attributes---How to copy, change, and undefine graphics characteristics
- Defining graphics characteristics efficiently---How to work efficiently with several sets of graphics characteristics
Chapter 6 describes how to create graphics objects. Chapter 8
describes how to work with text.
4.1 The Graphics Context
The characteristics of a graphics object make up its graphics context. As with window characteristics, Xlib provides a data structure and routine to enable clients to define multiple graphics characteristics easily. By setting values in the GC values data structure and calling the CREATE GC routine, clients can define all characteristics relevant to a graphics object.
Xlib also provides routines that enable clients to define individual or functional groups of graphics characteristics.
Xlib always records the defined values in a GC data structure, which is reserved for the use of Xlib and the server only. This occurs when clients define graphic characteristics using either the CREATE GC routine or one of the individual routines. Table 4-1 lists the default values of the GC data structure.
| Member Name | Default Value |
|---|---|
| Function | x$c_gx_copy |
| Plane mask | All ones |
| Foreground | 0 |
| Background | 1 |
| Line width | 0 |
| Line style | Solid |
| Cap style | Butt |
| Join style | Miter |
| Fill style | Solid |
| Fill rule | Even odd |
| Arc mode | Pie slice |
| Tile | Pixmap of unspecified size filled with foreground pixel |
| Stipple | Pixmap of unspecified size filled with ones |
| Tile or stipple x origin | 0 |
| Tile or stipple y origin | 0 |
| Font | Varies with implementation |
| Subwindow mode | Clip by children |
| Graphics exposures | True |
| Clip x origin | 0 |
| Clip y origin | 0 |
| Clip mask | None |
| Dash offset | 0 |
| Dashes | 4 (the list [4,4]) |
4.2 Defining Multiple Graphics Characteristics in One Call
Xlib enables clients to define multiple characteristics of a graphics object in one call. To define multiple characteristics, use the CREATE GC routine as follows:
- Assign values to the relevant members of the GC values data structure.
- Indicate the attributes to define by specifying the appropriate flag and passing the flag to the value_mask argument of the routine. To define more than one attribute, perform a bitwise OR on the appropriate attribute flags.
Figure 4-1 illustrates the GC values data structure.
Figure 4-1 GC Values Data Structure
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 2^n , 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.
5.1.1 Installing Color Maps
5.1.1Installing 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
5.2.1Visual 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
5.2.2 Determining the Default Visual Type
5.2.2Determining 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 X$L_VISU_CLASS member of the data structure to determine the visual type.
. . . CALL X$DEFAULT_VISUAL_OF_SCREEN(SCREEN,VISUAL) . . . RECORD /X$VISUAL/ VISU IF (VISU.X$L_VISU_CLASS .EQ. X$C_TRUE_COLOR .OR. 1 VISU.X$L_VISU_CLASS .EQ. X$C_PSEUDO_COLOR .OR. 1 VISU.X$L_VISU_CLASS .EQ. X$C_DIRECT_COLOR .OR. 1 VISU.X$L_VISU_CLASS .EQ. X$C_STATIC_COLOR) THEN . . . |
5.2.3 Determining Multiple Visual Types
5.2.3Determining Multiple Visual Types On some systems, a single display can support multiple screens. Each screen can have several different visual types supported at different depths. Xlib provides routines that allow a client to search and choose the appropriate visual type on the system by using the visual info data structure. Figure 5-4 illustrates the visual info data structure. Figure 5-4 Visual Info Data Structure5643xvisual_info_pic.tex 0
Table 5-1 describes the members of the visual info data structure.
| Member Name | Contents |
|---|---|
| X$A_VISL_VISUAL | A pointer to a visual data structure that is returned to the client. |
| X$L_VISL_VISUAL_ID | The ID of the visual that is returned by the server. |
| X$L_VISL_SCREEN | The specified screen of the display. |
| X$L_VISL_DEPTH | The depth in planes of the screen. |
| X$L_VISL_CLASS | The class of the visual (X$C_PSEUDO_COLOR, X$C_GRAY_SCALE, X$C_DIRECT_COLOR, X$C_TRUE_COLOR, X$C_STATIC_GRAY, or X$C_STATIC_COLOR). |
| X$L_VISL_RED_MASK | Definition of the red mask. 1 |
| X$L_VISL_GREEN_MASK | Definition of the green mask. 1 |
| X$L_VISL_BLUE_MASK | Definition of the blue mask. 1 |
| X$L_VISL_COLORMAP_SIZE | Number of available color map entries. |
| X$L_VISL_BITS_PER_RGB | Number of bits that specifies the number of distinct red, green, and blue values. Actual RGB values are unsigned 16-bit numbers. |
1The red mask, green mask, and blue mask are defined only for the direct color and true color visual types.
| Previous | Next | Contents | Index |