The CDL component provides several services to applications using it. First and foremost, it provides a graphic, multi-layered 'canvas' on which (vector) drawings can be rendered. CDL takes care of the details involved in such actions as zooming, panning, providing multiple windows on different parts of the same list, changing the visibility of layers, selecting items (as with a mouse) and so on, as requested by the application.
CDL is also designed to be device-independent. That is, the graphic information is stored in an internal format that doesn't care how it will ultimately displayed. Each view onto a list associates itself with a particular display device class. The default class (and only one developed so far) displays to X Windows, but in this can be extended to raw SVGA, PostScript or Display PostScript, a pen plotter, and so on (within the limitations of the medium).
The basic unit of display (as far as an application is concerned) is a graphic object, or entity. Depending on the application and particular (real world) object, an entity may be anything from a single line or simple symbol to a very complex graphic comprising lines, shapes, different colors, text and so forth. (Internally, each entity is composed of graphic primitives, commands to do things like draw a line, set the color, move to a different point, etc. Primitives may also be grouped into symbols, essentially macros to provide for repeated use of the same sequence of primitives).
Entities in turn reside on different layers in the display. An application typically groups like objects on different layers, for example a GIS might put roads on one layer, rivers and lakes on another, buildings on a third, and so on. Within a layer, entities may also optionally be grouped into networks. For example a road layer might have different networks for interstates, state highways, and local roads. (In some applications network connectivity is an issue, but this is handled more by database attribute than visual or graphic connectivity.)
Thus, a display list consists of a list of layers, each of which contains a list of entities (and may also contain a list of networks, each of which contains a list of entities). Each entity in turn consists of a list of primitives which describe how to draw it. Each list also has associated with it one or more views (virtual windows into the list), and each view is associated with a display device, typically a window on an X display.
The current Display List manager can create and manage up to 8 different display lists simultaneously (if you need more, create more instances of CDL, I guess) and up to 8 views of each list. (A view is a virtual window onto the list. Anything that changes the list (e.g. changing the visibility of a layer, or adding a new object) will be reflected in all views onto that list, but each view can be independently zoomed, panned, resized, etc.
Other than that, CDL is only limited by available memory and word size. Internal identifiers for layers and entities (graphic objects) are 32-bit (currently) ints, giving you a few billion. World coordinates (what your application's information is stored in) are transformed to list coordinates for internal use by CDL, these are also 32-bits, which is sufficient to map, say, the United States to a precision of a millimeter or so.
Obviously, the more data you're displaying the slower will be things like searches around a point or operations like zoom and pan. (CDL doesn't take advantage of any such features that might be in your display hardware.)
Displaying several tens of thousands of features from a database can take some time, so CDL allows for saving the display list to disk and reloading it on demand (which can be much faster for a large display list) However, it's up to the application to ensure that the data hasn't changed such that a stored display list is no longer in sync with it.
There are two ways that CDL may be used (not counting tearing the source code apart and reusing that, of course). The first is for an object of CdlList class to be created in the application program and its methods used directly. (The app links to libCdl in this case). Alternatively (and the method used by CAVOR) the Display List Manager is started as a separate process. Applications communicate with it using CDLI (CAVOR Display List Interface) library calls (libCdli) to request the actions. This allows for overlapping the I/O of, for example, reading in data to be displayed and actually displaying it, without the headache of multi-threading the app itself. (Let the OS do the work, I always say.)