The X Windows Device

Device Keywords Accepted by the X Device:

BYPASS_TRANSLATION, COPY, CURSOR_CROSSHAIR, CURSOR_IMAGE, CURSOR_MASK, CURSOR_ORIGINAL, CURSOR_STANDARD, CURSOR_XY, DECOMPOSED, DIRECT_COLOR, FLOYD, GET_CURRENT_FONT, GET_FONTNAMES, GET_FONTNUM, GET_GRAPHICS_FUNCTION, GET_SCREEN_SIZE, GET_VISUAL_NAME, GET_WINDOW_POSITION, GET_WRITE_MASK, ORDERED, PSEUDO_COLOR, RETAIN, SET_CHARACTER_SIZE, SET_FONT, SET_GRAPHICS_FUNCTION, SET_TRANSLATION, SET_WRITE_MASK, STATIC_COLOR, STATIC_GRAY, THRESHOLD, TRUE_COLOR, TTY, WINDOW_STATE

X Windows is a network-based windowing system developed by MIT's project Athena. IDL uses the X System (often referred to simply as "X"), to provide an environment in which the user can create one or more independent windows, each of which can be used for the display of graphics and/or images.

In the X system, there are two basic cooperating processes: clients and servers. A server consists of a display, keyboard, and pointer (such as a mouse) as well as the software that controls them. Client processes (such as IDL) display graphics and text on the screen of a server by sending X protocol requests across the network to the server. Although in the most common case, the server and client reside on the same machine, this network based design allows much more elaborate configurations.

To use X Windows as the current graphics device, issue the IDL command:

SET_PLOT, 'X' 

This causes IDL to use the X Window System for producing graphical output. Once the X driver is enabled via SET_PLOT, the DEVICE procedure is used to control its actions, as described below.

Use the statement:

HELP, /DEVICE 

to view the current state of the X Windows driver.

Multi-Monitor Configurations and X Windows

IDL supports multiple monitor configurations on X Windows in two ways:

Direct Graphics Limitations

In an X Multi-Screen configuration you can open a Direct Graphics window only on the default Display connection. This applies both to stand-alone Direct Graphics windows (e.g., PLOT) and WIDGET_DRAW widgets created with the GRAPHICS_LEVEL keyword set equal to any value other than 2.

In an XINERAMA configuration you can draw Direct Graphics on any monitor. This is because the extended desktop is one logical connection and is addressed with one X Display Name.

See the IDLsysMonitorInfo object for more information.

X Windows Visuals

Visuals specify how the hardware deals with color. The X Window server (your display) may provide colors or only gray scale (black and white), or both. The color tables may be changeable from within IDL (read-write), or may be fixed (read-only). The value of each pixel value may be mapped to any color (Un-decomposed Colormap), or certain bits of each pixel are dedicated to the red, green, and blue primary colors (Decomposed Colormap).

There are six X Windows visual classes—read-write and read-only visuals for three types of displays: Gray Scale, Pseudo Color, and Decomposed Color. The names of the visuals are shown in the following table:

IDL supports all six types of visuals, although not at all possible depths. UNIX X Window System users can use the command xdpyinfo to determine which visuals are supported by their systems.

Each X Window server has a default visual class. Many servers may provide multiple visual classes. For example, a server with display hardware that supports an 8-bit-deep, un-decomposed, writable color map (PseudoColor), may also easily provide StaticColor, StaticGray, and GrayScale visuals.

You can select the visual used by IDL using the DEVICE procedure before a window is created, or by including the resource idl.gr_visual in your X defaults file, as explained in Setting the X Window Defaults.

How IDL Selects a Visual Class

When opening the display, IDL asks the display for the following visuals, in order, until a supported visual class is found:

You can override this behavior by using the DEVICE routine to specify the desired visual class and depth before you create a window. For example, if you are using a display that supports both the TrueColor, 24-bit-deep visual, and an 8-bit-deep PseudoColor visual, IDL will select the 24-bit-deep TrueColor visual. To instead use PseudoColor, issue the following command before creating a window:

DEVICE, PSEUDO_COLOR = 8 

The colormap/visual class combination is chosen when IDL first connects with the X Window server. Note that if you connect with the X server by creating a window or using the DEVICE keyword to the HELP procedure, the visual class will be set; it then cannot be changed until IDL is restarted. If you wish to use a visual class other than the default, be sure to set it with a call to the DEVICE procedure before creating windows or otherwise connecting with the X Window server.

Windows are created in two ways:

Once the visual class is selected, all subsequently-created windows share the same class and colormap. The number of simultaneous colors available is stored in the system variable !D.N_COLORS. The visual class and number of colors, once initialized, cannot be changed without first exiting IDL.

How IDL Obtains a Colormap

IDL chooses the type of colormap in the following manner:

Using Color Under X

Colormaps define the mapping from color index to screen color. Two attributes of colormaps are important to the IDL user: they may be private or shared; and they may be static or writable. These different types of colormaps are described below.

Shared Colormaps

The window manager creates a colormap when it is started. This is known as the default colormap, and can be shared by most applications using the display. When each application requires a colormap entry (i.e., a mapping from a color index to a color), it allocates one from this shared table. Advantages and disadvantages of shared colormaps include:

Private Colormaps

An application can create its own private color map. Most hardware can only display a single colormap at a time, so these private colormaps are called virtual color maps, and only one at a time is actually in use and visible. When the window manager gives the color focus to a window with a private colormap, the X window system loads its virtual colormap into the hardware colormap.

Static Colormaps

As mentioned above, the contents of static colormaps are determined outside of IDL and cannot be changed. When using a static colormap, the TVLCT procedure simulates writable colormaps by finding the closest RGB color entry in the colormap to the requested color. The colormap translation table is then set to map IDL color indices to those of the closest colors in the colormap.

The colors present in the colormap may, and probably will, not match the requested colors exactly. For example, with a typical static color map, loading the IDL standard color table number 0, which consists of 256 intensities of gray, results in only 8 or 16 distinct intensities.

With static colormaps, loading a new color table does not affect the appearance of previously written objects. The internal translation tables are modified, which only affects objects that are subsequently written.

Color Translation

As mentioned above, colors from the shared colormap do not necessarily start from index zero, and are not necessarily contiguous. IDL preserves the illusion of a zero based contiguous colormap by maintaining a translation table between user color indices, which range from 0 to !D.TABLE_SIZE, and the actual pixel values allocated from the X server. Normally, the user need not be concerned with this translation table, but it is available using the statement:

DEVICE, TRANSLATION=T 

This statement stores the current translation table, a 256 element byte vector, in the variable T. Element zero of the vector contains the value pixel allocated for the zeroth color in the IDL colormap, and so forth. In the case of a private colormap, each element of the translation vector contains it's own index value, because private colormaps start at zero and are contiguous.

The translation table may be bypassed, allowing direct access to the display's color indices, by setting the BYPASS_TRANSLATION keyword in the DEVICE procedure.

DEVICE, /BYPASS_TRANSLATION 

Translation can be reestablished by setting the keyword to zero:

DEVICE, BYPASS_TRANSLATION=0 

By default, the color translation tables are bypassed if the visual type is TrueColor or the visual type is DirectColor with a private colormap.

Using Pixmaps

X Windows can direct graphics to windows or pixmaps. Windows are the usual windows that appear on the screen and contain graphics. Pixmaps are invisible graphics memory contained in the server. Drawing to a window produces a viewable result, while drawing to a pixmap simply updates the pixmap memory.

Pixmaps are useful because it is possible to write graphics to a pixmap and then copy the contents of the pixmap to a window where it can be viewed. Furthermore, this copy operation is very fast because it happens entirely within the server. Provided enough pixmap memory is available, this technique works very well for animating a series of images by placing the images into pixmap memory and then sequentially copying them to a visible window.

To create a pixmap, use the PIXMAP keyword with the WINDOW procedure. For example, to create a square pixmap with 128 pixels per side as IDL window 1, use the command:

WINDOW, 1, /PIXMAP, XSIZE=128, YSIZE=128 

Once they are created, pixmaps are treated just like normal windows, although some operations (WSHOW for instance) don't do anything useful when applied to a pixmap.

The following procedure shows how animation can be done using pixmap memory. It uses a series of 15 heart images taken from the file abnorm.dat. This file is supplied with all IDL distributions in the examples/data subdirectory of the main IDL directory. It creates a pixmap and writes the heart images to it. It then uses the COPY keyword of the DEVICE procedure to copy the images to a visible window.

Note
Pressing any key causes the display process to halt. If you are using the IDL Workbench interface, make sure the IDL Command Line view has the focus before pressing a key.

 
; Animate heart series: 
PRO animate_heart 
; Open the file containing the images: 
OPENR, u, FILEPATH('abnorm.dat', SUBDIR = ['examples','data']), $ 
   /GET_LUN 
; Associate a file variable with the file. Each heart image  
; is 64x64 pixels: 
frame = ASSOC(u, BYTARR(64,64, /NOZERO)) 
; Window 0 is a pixmap which is 4 images tall and 4  
; images wide. The images will be placed in this pixmap: 
WINDOW, 0, /PIXMAP, XSIZE = 512, YSIZE = 512 
; Write each image to the pixmap. SMOOTH is used to improve  
; the appearance of each image and REBIN is used to  
; enlarge/shrink each image to the final display size: 
FOR i=0, 15-1 DO TV, REBIN(SMOOTH(frame[i],3), 128, 128),i 
; Close the image file and free the file unit: 
FREE_LUN, u 
; The visible window will be used to display the animated heart 
; cycle: 
WINDOW, XSIZE = 128, YSIZE=128, TITLE='Heart', /FREE 
; Current frame number: 
i = 0L 
; Display frames until any key is pressed: 
WHILE GET_KBRD(0) EQ '' DO BEGIN 
; Compute x and y locations of pixmap image's lower left corner: 
   x = (i mod 4) * 128 & y = 384 - (i/4) * 128 
; Copy the next image from the pixmap to the visible window: 
DEVICE, COPY = [x, y, 128, 128, 0, 0, 0] 
; Keep track of total frame count: 
i = (i + 1) MOD 15 
ENDWHILE 
END 

Animation sequences with more and/or larger images can be made. See the documentation for the XANIMATE procedure, which is a more generalized embodiment of the above procedure.

Note
Some X Windows servers will refuse to create a pixmap that is larger than the physical screen in either dimension.

Note
Excessive pixmap allocation can exhaust virtual storage, causing some X Windows servers to become unresponsive.

How Color is Interpreted for a TrueColor Visual

How a color (such as !P.COLOR) is interpreted by IDL (when a TrueColor visual is being utilized) depends in part upon the decomposed setting for the device.

To retrieve the decomposed setting:

DEVICE, GET_DECOMPOSED = currentDecomposed 

To set the decomposed setting:

DEVICE, DECOMPOSED = newDecomposed 

If the decomposed value is zero, colors (like !P.COLOR) are interpreted as indices into IDL's color table. A color should be in the range from 0 to !D.TABLE_SIZE - 1. The IDL color table contains a red, green, and blue component at a given index; each of these components is in the range of 0 up to 255.

Note
IDL's color table does not map directly to a hardware color table for a TrueColor visual. If IDL's color table is modified, for example using the LOADCT or TVLCT routines, then the new color table will only take effect for graphics that are drawn after it has been modified.

If the decomposed value is non-zero, colors (like !P.COLOR) are interpreted as a combination of red, green, and blue settings. The least significant 8 bits contain the red component, the next 8 bits contain the green component, and the most significant 8 bits contain the blue component.

In either case, the most significant bits of each of the resulting red, green, and blue components are utilized. The number of bits utilized per component depends upon the red, green, and blue masks for the visual. On UNIX systems, a new field (Bits Per RGB) has been added to the output from HELP, /DEVICE. This Bits Per RGB field indicates the amount of bits utilized for each component.

Tip
The UNIX command xdpyinfo also provides information about each of the visuals.

Setting the X Window Defaults

You can set the initial default value of the following parameters by setting resources in the file .Xdefaults file in your home directory as follows:

For example, to set the default visual to PseudoColor, and to allocate 100 colors, insert the following lines in your defaults file:

idl.gr_visual: PseudoColor 
idl.colors: 100