Module Display

Changes made in the current development cycle can be found in the changelog.

Description (classes)

A module providing graphical display classes for use with AIPS++

Prerequisite

Review Status

Reviewed By:
None yet
Date Reviewed:
yyyy/mm/dd

Etymology

Module provides classes for an Image Display Library

Synopsis

The purpose of the Display library is twofold: 1) to provide a set of tools for the AIPS++ programmer which make it easier to create drawing windows and use those drawing windows as output devices for graphical primitives, including images, and 2) to provide a set of higher- level classes to display datasets in a number of ways (images, contours, ...) as well as classes to help build an application that needs to display several datasets.

A design goal is to have Display Library applications portable to another graphics system by augmenting the Library to provide an interface to that graphics system.

  1. Display Library Overview
  2. PixelCanvas
    1. Drawing Commands
    2. Event Handling
    3. Caching Mechanism
    4. Colormap System
  3. WorldCanvas
    1. Drawing Commands
    2. Event Handling
    3. Other Handlers
  4. WorldCanvasHolder
  5. DisplayData
  6. Zoomer
  7. Animator


Display Library Overview

The Display library is a set of tools for the AIPS++ programmer which make it easier to create drawing windows and use those drawing windows as output devices for graphical primitives, including images. To some extent, the Display Library consists of two parts. One part is a set of device indepentent classes that give the basic functionality for data display. The classes of the first group are quite generic and can basically be used for any application that needs an interactive display window and these classes not tied to AIPS++ data sets or AIPS++ coordinate systems. They make only very few assumptions for what they will be used. The second part is more concerned with transforming data sets into objects that are understood by the first layer, as well as classes that should make it easier to build a full application that displays data. The classes of the second group can be quite data specific.

The main classes from the first group are the PixelCanvas, the WorldCanvas and the ColorMap classes. The PixelCanvas conceptually corresponds to the window on the screen. It works only in 'screen' units, ie. screen pixel coordiantes and screen data values. The PixelCanvas is, to some extent, the interface between Aips++ and the display hardware and graphics environment (e.g. X11). The WorldCanvas is mostly an interface layer between the 'real world' and the PixelCanvas. Its main responsibility is to transform drawing instruction that are specified in world coordinates and world values to the corresponding instructions of the PixelCanvas specified in pixel coordinates and pixel values. The PixelCanvas and the WorldCanvas are intended to be relatively 'raw' devices. With this we mean that both classes have basically no knowledge of the classes that use these Canvases to display data. In effect, The PixelCanvas does not know what a WorldCanvas is. The reason to make the canvases relatively ignorant, is that by putting in as few assumptions as possible in the canvases, they (hopefully) can be used in a very wide range of applications. For example, it is quite easy to make a 2D colormap editor (an application that is quite different from e.g. displaying a contour map) based on the PixelCanvas or on the WorldCanvas. To achieve that only a few assumption have to be built in in the canvases, the canvases communicate to other classes via event handlers that these other classes have to register with the canvases. Also the PixelCanvas communicates with the WorldCanvas thourg such event handlers. For example, if the window corresponding to the Pixelcanvas is resized by the user, this generates a refresh event and the Pixelcanvas calls the refresh event handlers registered with the PixelCanvas. When a WorldCanvas is created, the first thing the WorldCanvas does is to install a number of event handlers on the PixelCanvas. This means that if e.g. the refresh event occurs on the PixelCanvas, the WorldCanvas is notified and takes the necessary action. This scheme of communication through event handlers is used throughout the Display Library. The classes that generate events do not have to know what classes consume these events, the only thing that is defined is the interface (and content) of the event. This means that one could build a class on top of the PixelCanvas that is quite different from the WorldCanvas.

To keep the WorldCanvas as generic as possible, the coordinate system the WorldCanvas uses to transform from screen pixels to world coordinates and back is not stored in the WorldCnvas but is also defined through an event handler (a CoordinateHandler). If the WorldCanvas has to do a coordinate transformation, it asks the CoordinateHandler to do this. In many cases, this CoordinateHandler will use a standard Aips++ CoordinateSystem to do the transformation, but this is not a requirement, and the programmer can implement any tranformation required, as long as it satisfies the interface of the CoordinateHandler.

The features of the first group include

The classes of the second group have a quite different purpose. They are much more concerned with building an application that needs to display one or more aips++ datasets in a number of ways.

To make the link between the relatively generic display classes (PixelCanvas, WorldCanvas etc) and classes quite specific for displaying Aips++ datasets, an intermediate class is required. This class is called the WorldCanvasHolder. The main role of the WorldCanvasHolder is to catch the events that occur on a WorldCanvas and distribute these events to the data that is being displayed on the Worldcanvas. Another important role of the WorldCanvasHolder is that it is the class that is used to control what is actually displayed on the WorldCanvas. One important design requirement for the Display Library was that, from the programmer point of view, it should be easy to display more than one dataset in a window at the same time. A standard example is a contourmap on top of a greyscale image. Consequently, one can register more than one display object with the WorldCanvasHolder so that they are displayed at the same time.

One important aspect that the WorldCanvasHolder takes care of is the sizeControl of the WorldCanvas. If a refresh event happens on the WorldCanvas, before invoking the refresh event handlers installed on the WorldCanvas, the WorldCanvas invokes a sizeControl event. The meaning of this event is to ask the object that draws on the WorldCanvas (e.g. the WorldCanvasHolder) to check if the state of the WorldCanvas is ok so that it can be drawn on, and if it is not ok, that the state of the WorldCanvas be modified. For example, if an image is drwan as a pseudeocolor image and the window (or WorldCanvas) is much larger that the data array, one wants to expand the data array so that it fills more or less the window. One way of doing this is to do this by pixelreplication. But this means that there are requirements on the size of the area that the WorldCanvas uses for drawing the image (it has to be a integer multiple of the size of the data array. This explains the name sizeControl). It is the responsibility of the objects that draw on the WorldCanvas, to get these size right. What in practice happens is that the WorldCanvasHolder asks the display objects to sort this out and set the correct size on the WorldCanvas. Once this is sorted out, the WorldCanvas is in the coreect state and things can be drawn. The name sizeControl is not entirely correct. The obvious use of this mechanism is as in the example described above, but the problem is more general: before display objects can draw on the WorldCanvas they have to be sure that the WorldCanvas is in the correct state and possibly they have to modify the attributes of the WorldCanvas. Because more than one display object can draw on the WorldCanvas, this has to be done before the actual drawing occurs (because the display objects do not know if there are more than one display objects drawing on the WorldCanvas).

Another requirement for the Display Library was that no distinction should be made based on how data is displayed. For example, displaying an image as a pseudocolor image on the screen should, from the Display Library point of view, be the same operation as displaying that image as a contourmap. This means that the display object is quite an 'abstract' class. Display Objects in the Display Library are called DisplayData (or better: are derived from DisplayData). The role of the DisplayData is, using a certain algorithm, to transform data into one or more draw instructions for the WorldCanvas. An example is ImageDisplayData that takes an Aips++ dataset and display its contents as images, Another example would be ContourDisplayData that draws images as contourmaps. Also here, the communication to the DisplayData goes via calling event handlers. Depending on what happens (e.g. a refresh event, or a position event), the WorldCanvasHolder (who catches these events from the WorldCanvas), invokes member functions of the DisplayData registered with the WorldCanvasHolder (so to a large extent, a DisplayData is an event handler on the WorldCanvasHolder). For example, if a refresh event happens, the WorldCanvasHolder will ask the DisplayData to draw what they should draw. If a programmer wants to implement a new way of displaying data, what this programmer has to do is to implement a new class derived from DisplayData that computes whatever it has to compute (say a volume rendering of a datacube) and transform this into draw instructions for the WorldCanvas (in this example, just call WorldCanvas.drawImage() on the result of the volume rendering). A class derived from DisplayData does not need to have an Aips++ dataset, but one could for example image a DisplayData class that reads positions from a catalog and plots these positions on the WorldCanvas.

Because everything in the Display Library is event driven, it is also easy to make applications that require more than one display window. The programmer only has to decide how to link the various windows by installng the appropriate event handlers on the various classes. An example of how this can be done is the Zoomer class. This class is a high-level class that catches position events on the WorldCanvases (possibly more than one) that are registered with the Zoomer. If the right event happens on one of the WorldCanvases (say, the user is rubberbanding a rectangle), the Zoomer sets the correct attributes on all the WorldCanvases registered with the Zoomer (meaning: it defines the area to which should be zoomed in) and invokes a refresh event on all these WorldCanvases. This means that all the WorldCanvases will zoom in synch.

Another design requirement of the Display Library was that it should be easy to display movies, and the DisplayData are build with sequences in mind (as is clear from their interface). The programmer is free to define what a sequence really means, but it is probably best to keep the structure of the sequence in a DisplayData logical to at least some extent. But there is no real requirement on the structure of the sequence. Movies can be controlled using the Animator class. The easy way is to use indices, but there is a generic way of defining movies using restrictions (see later what these mean). So a sequence does not have to correspond to a 'physical' sequence in one datastructure (channels in a cube for example), but can be made of representations of different datasets (e.g. blinking), or more exotic combinations of different datasets displayed in different form (e.g. blink between a greyscale and a contourmap, if such a thing would be useful). This system is very flexible and there are no real limits to what a movie really means.

An important concept in the Display Library is that of Attributes (and their use as restrictions). Attributes are name-value pairs. Many classes of the Display Library have a buffer where they can store these Attributes. They can be used for various things (see AttributeBuffer for a number of examples). One applications is that a uniform userinterface can be defined for changing attributes of a class (meaning internal members), but since Attributes can have an arbitrary name, they can be used to place (almost) any kind of information on classes at run time. This provides a mechanism of distributing information in a display aplication, while at compile time it is not yet defined what that information is (name, type, etc).

An important application of Attributes is their use as restrictions: they are used to select which data is actually displayed. DisplayData classes, like ImageDisplayData, are supposed to have defined, for each distinct representation that they can draw, one or more Attributes, specifically defined to select what data is displayed. These Attributes are in a separate (or several separate) AttributeBuffer, called the restriction buffer. Also the WorldCanvasHolder has such a restriction buffer whose content should be controlled by the application programmer. If a refresh happens, the WorldCanvasHolder, after the sizeControl step, asks each DisplayData that is registered with the WorldCanvasHolder to draw itself, by calling the refreshEH() member of each DisplayData. The first thing that a DisplayData should do it to see if the restrictions that are placed on the WorldCanvasHolder are compatible with this DisplayData and/or check with which element of the DisplayData the restriction buffer WorldCanvasHolder is compatible. If the DisplayData has compatible data, it should draw this data. An example may make this process clearer. An ImageDisplayData is a class derived from DisplayData that displays the 2D slices from a n-dimensional dataset on a canvas (for example the channels from a datacube). An ImageDisplayData has two general restrictions (meaning they apply to all channels): the names of the axes ("xAxisName" = "Ra" and "yAxisName" = "Dec"). Since an ImageDisplayData (possibly) consists of a number of channels, additional restrictions exist, but these have a different value for each element (ie. channel). In the case of an ImageDisplayData, each 2D subset has defined "zIndex" and "zValue", the first has the value of the pixelcoordinate of the 2D image (in our example channel number), the second has the value of the WorldCoordinate of centre of the 2D image (in our example the velocity of the channel). So to display a channel, a programmer has to set 3 restrictions on the WorldCanvasHolder: "xAxisName", "yAxisName" to select channels from a datacube and set these to "Ra" and "Dec" (or whatever is in the header of the data), plus a restriction to select the actual channel, e.g. set "zIndex" to 20 to select channel 20, or "zValue" to 1200.0, to select the channel corresponding to velocity 1200.0. To display a position velocity image, one would have to specify e.g. "xAxisName" = "Dec" and "yAxisName" = "Velocity" and set "zValue" to 5.23443311 (the Ra of the slice you want to look at).

To determine if restrictionbuffers match, one can simply use the member matches() of an AttributeBuffer. The logic of matching restrictions is perhaps a bit distorted: restrictions (or Attributes in general) of different names always match. So if a DisplayData has a restriction called "A" and the WorldCanvasHolder specifies "B", the DisplayData should draw itself. Restrictions (and Attributes) can have some tolerance. In our example we could have specified "zValue" to be 1200.0, plus or minus 5.0. This obviously can be used e.g. to match the channels of two data cubes that are on a different velocity grid. The Animator class, who can be used to make movies, completely relies on this restriction mechanism.


The PixelCanvas

The PixelCanvas display library defines an interface to an underlying 2D graphics library.

The design of the PixelCanvas emphasizes the following features:

PixelCanvas Drawing Commands

PixelCanvas drawing commands accept simple AIPS++ objects. Presently the drawing commands accept points as Vector's, where t can be any scalar type but Bool. Bool images are not supported because a Bool cannot represent a color index. Complex values are not supported because there are many ways of creating a single scalar value from complex values.

PixelCanvas Event Handling

There are 3 kinds of events the PixelCanvas reports

  1. refresh event - sent when the canvas must be redrawn.
  2. position event - sent when a button or key is pressed.
  3. motion event - sent when the mouse moves over the cursor.

Applications handle PixelCanvas events by creating PixelCanvas event handlers that must be derived from the appropriate event class, either PCRefreshEH, PCPositionEH, or PCMotionEH. The () operator must be overridden and implemented by responding to the information contained in the PCRefreshEvent, PCPositionEvent, or PCMotionEvent, as appropriate.

PixelCanvas Caching Mechanism

There is a system for creating sequences of commands. It works be turning on caching, performing drawing commands, then shutting it off. An id is returned to the user to recall the stored sequence. This gives the user control over what is to be cached while still abstracting the business of caching.

The cache system improves drawing speed by storing drawing data in native library formats.

Data stored in native formats means that, for the X11PixelCanvas,

It is the responsibility of the user to rebuild display lists when necessary. Normally this means when the canvas changes size or colormap distribution (if colormaps are in use).

PixelCanvas Colormap System

The PixelCanvas colormap system design was one of the most difficult design problems we faced in building this system. The design goals were as follows:

  1. Wanted to be able to pretend we had multiple simultaneous colormaps available in some display window.
  2. Wanted to allow for but not demand that multiple windows share the same hardware colormap.
  3. Wanted to distribute the same colormap to different windows potentially displaying on different terminals.
  4. Wanted to allow for customizing the colormaps, and allow for data-dependent colormaps.
  5. Wanted to be able to resize the available colormap while a Display library application was running.

The constraints above have driven us to the following scheme:

  1. Create something called a PixelCanvasColorTable and let it define a table of available colors for one or more PixelCanvases and be responsible for interfacing to the underlying graphics system's color allocation facilities. Through the PixelCanvasColorTable one can abstract away the underlying graphic library's tedious and cumbersome constructs and functions required to manage color resources and visuals and provide a high-level interface based on concepts that are better understood. This interface is implemented as the constructors for the classes derived from the PixelCanvasColorTable class.

  2. Define a Colormap to mean not a table of colors, but rather a function that takes a floating-point parameter in [0.0,1.0] and returns an RGB triple. This function can then be used to fill some arbitrary number of consecutive colorcells. Allow for Colormaps to be of a fixed size if needed (then they are called 'rigid') and design them for derivation so custom colormaps can be created and used in this system.

  3. Define a ColormapManager to be responsible for dynamically partitioning its PixelCanvasColorTable into chunks, one chunk for each registered Colormap, allowing for rigid Colormaps (that must be for some reason of a particular size) and weights to give greater color resolution to certain maps. Make it responsible for filling in the color based on its distribution of Colormaps in the PixelCanvasColorTable.

  4. Allow for PixelCanvasColorTables to be shared by more than one PixelCanvas, and allow PixelCanvases to share Colormaps.

  5. Try to abstract away all this mess by placing gateways to necessary functionality in the PixelCanvas itself. For example images are drawn on the PixelCanvas through the following process:

    1. register a Colormap with the PixelCanvas (needed only once).
    2. set the active colormap to the one used in step 1.
    3. create an image whose values range from 0 to N-1, where N is the size of the active colormap (PixelCanvas::getColormapSize()).
    4. call PixelCanvas::mapToColor(). to convert to color values.
    5. call PixelCanvasdrawImage() with the Matrix of color values

    The color image can be reused as long as the distribution of colors on the PixelCanvasColorTable doesn't change. Any such change will trigger a refresh event with the reason Display::ColorTableChange on the affected PixelCanvas. This process can also be used to draw other primitives that each have a value associated with it. Several colormaps can be switched between by setting the active colormap and querying the range, and using the mapToColor function.

  6. Implement a function that resizes the PixelCanvasColorTable, forcing a redistribution of colormaps on affected PixelCanvases followed by a refresh event. This ultimately causes a reallocation of writable color cells on the underlying graphics library and can be used to increase or decrease the number of color cells available to the PixelCanvasColorTable and hence to the application. This mechanism can be used to recover allocated color cells from the system map released by other applications when they exit, or to balance color resources between two or more applications.


The WorldCanvas

The WorldCanvas is intended to serve as a world-coordinate plotting canvas

WorldCanvas DrawingCommands

The WorldCanvas drawing commands expect to be given world coordinate values for position information.

WorldCanvas Event Handling

The WorldCanvas event handling is similar to the PixelCanvas event handling, but the WorldCanvas events contain extra information which includes the world coordinate and linear coordinate position of the mouse pointer. The same basic three events are available:

  1. refresh event - sent when the canvas must be redrawn.
  2. position event - sent when a button or key is pressed.
  3. motion event - sent when the mouse moves over the cursor.

Applications handle WorldCanvas events by creating WorldCanvas event handlers that must be derived from the appropriate event class, either WCRefreshEH, WCPositionEH, or WCMotionEH. The () operator must be overridden and implemented by responding to the information contained in the WCRefreshEvent, WCPositionEvent, or WCMotionEvent, as appropriate.

Other WorldCanvas Handlers

Other handlers can be registered with the WorldCanvas to customize:

The WorldCanvasHolder

The WorldCanvasHolder is a user of a WorldCanvas. It installs handlers on the WorldCanvas for each event a WorldCanvas can generate. The main role of the WorldCanvasHolder is to allow to have more than one DisplayData object draw on a WorldCanvas (e.g contours on top of an image). A number of DisplayDatas can be registered with a WorldCanvasHolder, and the WorldCanvasHolder passes WorldCanvas events to these DisplayData. To control what is displayed on a WorldCanvas, the programmer can put restrictions on a WorldCanvasHolder. Only those DisplayData do actually draw whose restrictions match those of the WorldCanvasHolder. See the example given above, or have a look at the doc of the Animator.

The DisplayData Interface

A DisplayData is the class that transforms data (in whatever form: an image, a cube, a catalog or whatever) into drawing instructions for the WorldCanvas. A DisplayData is the 'workhorse' of the display libary: here is defined in what way on can represent data. If one want to add a new way of displaying data to aips++, they only thing that has to be done is to write a new class, derived from DisplayData, that computes this new representation and draws it. For example, if one would want to add volume rendering to aips++, one would have to write a class that computes this volume rendering (e.g. using some hot-gas algorithm), and draw the result of this on a WorldCanvas (ie. simply WorldCanvas.drawImage() on the result). DisplayDatas are registered witha WorldCanvasHolder and the restriction mechanism is used to select what is being displayed. DisplayDatas are also responsible for defining the WorldCoordinate system of the WorldCanvas (they have an interface that can be called (indirectly) by the WorldCanvas to do the transformations), as wel las they have to insure that the state of the WorldCanvas is ok (the sizeControl, see above). An example of a DisplayData is the ImageDisplayData class, that draws pseudocolor images from a data set.

The Zoomer

Zooming is done by setying the linear coordinates of the WorldCanvas to define the zoom area (using a set function of the WorldCanvas) and force a refresh of the WorldCanvas. The Zoomer class defines the userinterface for zooming. One can register one (or more) WorldCanvas with a Zoomer. This Zoomer installs a position event handler on the WorldCanvas that listens to certain key- and mouse events. The Zoomer defines a default userinterface, but this can be re-defined. A Zoomer can also handle more than one WorldCanvas, so it is easy to let different WorldCanvases zoom in synch.

The Animator

The role of the Animator is to give an easy way of controling what is displayed on one or more WorldCanvases. By specifying how an Animator controls what is displayed (by using indices, world coordinates or restrictions), the Animator sets the necessary restrictions on the WorldCanvasHolders that are registered with the Animator, and forces a refresh on all of them. All WorldCanvasHolder registered on an Animator move in synch.


Motivation

Need to provide some usefull tools to assist in developing graphical C++ applications, addressing the problems encountered in trying to use other graphical libraries.


This section is intended as information about what tasks remain to be accomplished for the Display library.

The following list illustrates work remaining at the PixelCanvas level:

To Do

The following is the todo list for the WorldCanvas and related classes

To Do

The following is the todo list for the application level classes:

To Do


The following section is intended for a programmer who wants to improve the Display Library

Caching System Optimization

An advanced optimization to the PixelCanvas caching system would be to compact sequences of drawing commands. This would mean that a sequence received by the PixelCanvas would be transformed into a more efficient sequence of drawing commands that produces the same result. Obviously, sequences of the same commands can often be combined into a single command. But consider for example a drawn raster image I followed by a set of vectors V on top of the image. This sequence can be represented by { I V }.

We can partition V into 2 sets: Vin (contains vectors drawn inside the image) and Vout (vectors that have portions drawn outside the image). A new image I' can be created from I by drawing I onto a pixmap, then painting the vectors Vin on top, and storing the resultant image I'.

The cached sequence is then { I' Vout }, and I and V can be discarded This will result in faster drawing times and reduced memory usage if Vin has significant size because the vectors in Vin are not drawn explicitly.

Similar results can be achieved with drawn text and points, so that some sequence { I V P T } can be replaced with { I' Vout Pout Tout }. Also overlapping images can be stored to avoid drawing the overlapping region more than once.

It is not clear whether this would be worthwhile to pursue, so it has not been implemented.


Classes

AttValue -- Provision of type identification services for Attribute classes. (full description)
Attribute -- Arbitrary name-value pairs used in the display classes. (full description)
AttributeBuffer -- Buffer for storing Attributes (full description)
AttributeValue -- Type-dependent interface for values of Attributes. (full description)
AttributeValueBase -- Base class for values of Attributes used in the display classes. (full description)
AttributeValuePoi -- Templated class for storing a pointer to the value of an Attribute. (full description)
AttributeValuePoiTol -- Templated class for aliased, tolerant AttributeValues. (full description)
AttributeValueTol -- Templated class for storing Attributes which have a tolerance. (full description)
Color Distribution interface -- Global functions for generating color cube dimensions (full description)
Colormap -- Describes a method of generating a table of colors. (full description)
ColormapDefinition -- This class defines a wrapper for a color function or look-up table. (full description)
ColormapInfo -- ColormapInfo stores information about the dynamic mapping of a Colormap. (full description)
ColormapManager -- Class to manage registration of colormaps on PixelCanvasColorTables (full description)
DLFont -- A class designed to manage several representations of the same font (full description)
DParameterButton -- Implementation of DisplayParameter to package interface to button autoguis. (full description)
DParameterChoice -- Implementation of DisplayParameter to store choice parameters. (full description)
DParameterColorChoice -- Implementation of DParameterChoice to store color selection parameters. (full description)
DParameterFontChoice -- Implementation of DParameterChoice to store font selection parameters. (full description)
DParameterMapKeyChoice -- Implementation of DParameterChoice to store parameter and associated key (full description)
DParameterRange -- A helper class to deal with data ranges to support options (full description)
DParameterString -- Implementation of DisplayParameter to store String parameters. (full description)
DParameterSwitch -- Implementation of DisplayParameter to store choice parameters. (full description)
Display -- Enumerate constants for the display classes. (full description)
DisplayEnums to string functions -- Global functions (operators) to print display class enumerations. (full description)
DisplayParameter -- Base class for storing and parsing of parameters for display classes. (full description)
Driver functions called by FORTRAN PgPlot library -- Global driver functions need to support PgPlot on the WorldCanvas. (full description)
GLLogIO -- Support functions for GLPixelCanvas. (full description)
GLPCDisplayList -- DisplayListElement that can contain lists of other DisplayListElements. (full description)
GLPCDisplayListElement -- Base class for the various display list subclasses. (full description)
GLPCDisplayListEntry -- Returns a Display List Element for recording GL commands. (full description)
GLPCTextureParams -- Holds parameters for setting glTexParameteri variables. (full description)
GLPCTexturedImage -- (full description)
GLPixelCanvas -- OpenGL implementation of PixelCanvas. (full description)
GLPixelCanvasColorTable -- (full description)
GLTraceLevel -- (full description)
GLVColorTableEntry -- Implementation of PixelCanvasColorTable for OpenGL. (full description)
Global functions to attach to existing WorldCanvases -- Global utility functions need to support PgPlot on the WorldCanvas. (full description)
MultiWCHolder -- A holder of WorldCanvasHolders to use for panelling applications. (full description)
PCVGBuffer --

(full description)

PSDriver -- Low level interface between PSPixelCanvas{ColorTable} and PostScript. (full description)
PSPixelCanvas -- Implementation of the PixelCanvas for PostScript devices. (full description)
PSPixelCanvasColorTable -- Implementation of PixelCanvasColorTable for PostScript device. (full description)
PSWorldCanvasApp -- Simple PostScript WorldCanvas application (full description)
PanelDisplay -- A class which creates and manages "panelled" displays. (full description)
PgPlot driver definitions for stand-alone display applications -- Definitions of functions needed for stand-alone display applications. (full description)
PixelCanvas -- Base class defining interface to pixel-based output devices. (full description)
PixelCanvasColorTable -- Abstract interface to underlying graphics library's colortable (full description)
RGB/HSV Conversion Functions -- Utilities for converting between color spaces (full description)
SimplePixelCanvasApp -- Application class the provides basic gui for a PixelCanvas (full description)
SimpleRGBPixelCanvasApp -- Application class the provides basic gui for a PixelCanvas (full description)
SimpleWorldCanvasApp -- Simple application class providing a PixelCanvas and WorldCanvas. (full description)
SimpleWorldGLCanvasApp -- Simple application class providing a PixelCanvas and WorldCanvas. (full description)
SliceEH -- An event handler to negotiate between three different PanelDisplays (full description)
SlicePanelDisplay -- An application provide displays of three axis combinations of data in a cube (full description)
TkPixelCanvas -- Tk interface for PixelCanvas (full description)
VColorTableEntry -- Colormap entry for the virtual colormap. (full description)
WCPGFilter -- Interface between the WorldCanvas and its PGPLOT driver. (full description)
WorldCanvas -- Implementation of drawing in world coordinates on top of a PixelCanvas. (full description)
WorldCanvasHolder -- A holder to interface between DisplayDatas and a WorldCanvas (full description)
X11PCDLClear -- X11 display list object that stores the clear command (full description)
X11PCDLClearRegion -- X11 display list object that stores the clear command (full description)
X11PCDLColoredLines -- Class to store commands to draw colored lines on an X11PixelCanvas. (full description)
X11PCDLColoredPoints -- Class to store commands to draw colored points on an X11PixelCanvas. (full description)
X11PCDLDisable -- Class to store commands to disable clipping on an X11PixelCanvas. (full description)
X11PCDLDisplayList -- Class to store heirarchies of X11PixelCanvas display list objects. (full description)
X11PCDLEnable -- Class to store commands to enable clipping on an X11PixelCanvas. (full description)
X11PCDLFilledPolygon -- Class to store commands to draw a filled polygon on an X11PixelCanvas. (full description)
X11PCDLFilledRectangle -- Class to store commands to draw a filled rectangle on an X11PixelCanvas. (full description)
X11PCDLGraphicsContext -- Class to store context commands for X11PixelCanvases, eg. linewidth. (full description)
X11PCDLImage -- Class to store command for displaying an image on an X11PixelCanvas. (full description)
X11PCDLImageComponent -- Storing and caching of component (RGB/HSV) images for the X11PixelCanvas. (full description)
X11PCDLLine -- Class to store and cache X11PixelCanvas line command. (full description)
X11PCDLLines -- Class to store and cache X11PixelCanvas lines command. (full description)
X11PCDLLoadIdentity -- X11 display list object that stores the loadIdentity command (full description)
X11PCDLMaskedImage -- Class to store command for displaying a masked image on an X11PixelCanvas. (full description)
X11PCDLMaskedPixmap -- X11PixelCanvas display list object for masked pixmaps. (full description)
X11PCDLPixmap --

(full description)

X11PCDLPoint -- Class to store and cache X11PixelCanvas point command. (full description)
X11PCDLPoints -- Class to store and cache X11PixelCanvas points command. (full description)
X11PCDLPolyline -- Class to store and cache X11PixelCanvas polyline command. (full description)
X11PCDLPopMatrix -- X11 display list object that stores the popMatrix command (full description)
X11PCDLPushMatrix -- X11 display list object that stores the pushMatrix command (full description)
X11PCDLSetClearColor -- Class to store and cache X11PixelCanvas setclearcolor command. (full description)
X11PCDLSetClipWin -- Class to store and cache X11PixelCanvas setclipwin command. (full description)
X11PCDLText -- Class to store and cache X11PixelCanvas text command. (full description)
X11PCDLTranslate -- X11 display list object that stores the translate command (full description)
X11PixelCanvas -- Implementation of PixelCanvas for X11 devices. (full description)
X11PixelCanvasApp -- Application class the provides basic gui for a PixelCanvas (full description)
X11PixelCanvasColorTable -- Implementation of PixelCanvasColorTable for X11 devices. (full description)
X11ResourceManager -- Class to manage shared X11 resources among registered clients. (full description)
XTkPixelCanvas -- X Tk implementation of the PixelCanvas (full description)