 |
| |
BYPASS_TRANSLATION , COPY , CURSOR_CROSSHAIR , CURSOR_IMAGE , CURSOR_MASK , CURSOR_ORIGINAL , CURSOR_STANDARD , CURSOR_XY , DECOMPOSED , DIRECT_COLOR , FLOYD , FONT , GET_CURRENT_FONT , GET_FONTNAMES , GET_FONTNUM , GET_GRAPHICS_FUNCTION , GET_SCREEN_SIZE , GET_VISUAL_NAME , GET_WINDOW_POSITIONrf , GET_WRITE_MASK , ORDERED , PSEUDO_COLOR , RETAIN , SET_CHARACTER_SIZE , 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:
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.
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 X Windows Visual Classes .
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
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 DirectColor, 24-bit-deep visual, and an 8-bit-deep PseudoColor visual, IDL will select the 24-bit-deep DirectColor visual. To instead use PseudoColor, issue the following command before creating a window:
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:
1. Using the WINDOW procedure. WINDOW allows you to explicitly control many aspects of how the window is created.
2. If no windows exist and a graphics operation requiring a window is executed, IDL implicitly creates window 0 with the default characteristics.
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.
IDL chooses the type of colormap in the following manner:
allocates all but 8 of the currently available colors. This allows other applications that might need their own colors to run in tandem with IDL.
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.
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:
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.
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.
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:
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.
Translation can be reestablished by setting the keyword to zero:
When a private or static (read-only) color table is initialized, the bypass flag is cleared. It is set when initializing a shared color table.
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 data subdirectory of the images examples 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. Pressing any key causes the display process to halt:
PRO animate_heart ; Animate heart series.
OPENR, u, FILEPATH('abnorm.dat', SUBDIR = ['examples','data']), $
/GET_LUN; Open the file containing the images.
frame = ASSOC(u, BYTARR(64,64)); Associate a file variable with the file. Each heart image is 64x64 pixels.
WINDOW, pixwin, /PIXMAP, XSIZE = 512, YSIZE = 512, /FREE
;
Window pixwin is a pixmap which is 4 images tall and 4 images wide. The images will be placed in this pixmap.
FOR i=0, 15-1 DO TV, REBIN(SMOOTH(frame[i],3), 128, 128),i
;
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.
FREE_LUN, u ; Close the image file and free the file unit.
WINDOW, win, XSIZE = 128, YSIZE=128, TITLE='Heart', /FREE
;
Window win is a visible window. It will be used to display the animated heart cycle.
i = 0L ; Current frame number.
WHILE GET_KBRD(0) EQ '' DO BEGIN; Display frames until any key is pressed.
x = (i mod 4) * 128 & y = 384 - (i/4) * 128
;
Compute x and y locations of pixmap image's lower left corner.
DEVICE, COPY = [x, y, 128, 128, 0, 0, pixwin]
;
Copy the next image from the pixmap to the visible window.
i = (i + 1) MOD 15 ; Keep track of total frame count.
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.
You can set the initial default value of the following parameters by setting resources in the file .Xdefault s (Unix), or DECW$SM_GENERAL.DAT (VMS) in your home directory as follows:
|
The default setting for the retain parameter: 0=none, 1= by server, 2=by IDL. |
|
|
The type of visual: StaticGray, GrayScale, StaticColor, PseudoColor, TrueColor, or DirectColor. |
|
For example, to set the default visual to PseudoColor, and to allocate 100 colors, insert the following lines in your defaults file: