Understanding Layers for Graphical Applications

Graphical applications that display complex, multi-themed information must organise their display data into logical planes or layers. A simple approach to this is to draw the lowest layer first and the highest priority layer last, so ensuring that the overlay data correctly appears on top of the underlay. Although X Windows and Microsoft XP/Vista will provide the low-level primitives to draw the graphical data, there are many third-party toolkits (for example ILOG, InterMAPhics and ODS) available that simply the rendering of complex data sets. Many of these provide high-level modelling capabilities that seek to remove the complexities of the pixel drawing from the programmer, allowing them to concentrate on higher-level manipulation of real-world objects.

In some situations, the construction of a visible display by drawing each layer in sequence presents difficulties. Consider the situation where the display must be redrawn frequently to reflect the update of target information. Redrawing a complex display can become time-consuming, even with modern day processors and graphics cards. This is often the case for naval charts, which may be characterised by tens of thousands of polygons. A sensible approach to this problem is to retain the logical layers that are not changing in a separate buffer area, and then recompose the picture in stages. This works because the time to redraw a complex scene is significantly more then the time to copy an already rendered scene from one bitmap to another.

Another approach to constructing multi-layered displays is using bit planes. This works if the frame store contents are converted into colours through a look-up table - often called pseudo-color. In this technique separate logical layers can be written into different bitplanes of the frame store using a write-mask to restrict the updating to a specific plane. There are two problems with this approach. First of all, although the write mask restricts the update of pixel data to just one layer it is neverthless implemented as a read-modify-write of data in the frame store. In other words, data must be read, and then one bit position changed using a mask and finally the new value written back. As a consequence it is slow. (As an aside, there have been display controller that implement the write mask in hardware, so this issue is eliminated. However, these are uncommon and proprietary). The second issue with the bitplane updating is that is relies on a psedocolour display that maps pixel values to colours through a look-up table. In practice, it is more likely that a modern display application will want to use 24 or 32 bits of true colour per pixel.

A hardware solution to the display of multiple layers of data is to use a display architecture that directly supports multiple layers. In this situation one layer can be updated without affecting the others. One implementation of this might support an overlay and underlay layer, allowing complex, slowly changing layers to be drawn in the underlay independently of more simple but faster changing graphical layers in the overlay.

Displaying Radar Video

A further complication to the layering problem occurs with the need to display radar video. To be displayed correctly  radar video must be semi-transparently mixed with the underlay layer, so allowing the radar video to fade away to the colour of the undelying map. The overlays can then be presented on top of both the radar and the underlay. Presenting radar video in this way presents a number of challenges. Simple solutions, such as displaying the radar as an opaque underlay component, do not produce the quality of display that is demanded for most applications.

Once again, special-purpose display architectures provide a solution to this problem. By incoporating built-in support for the insertion of radar video as a layer in the display mixing process, the radar video can be combined with the underlay and then overlayed.

The SPx Approach to Multi-layer Windowing

SPx solves the challenging display problems in the presentation of radar video with complex multi-layer graphics, providing a software solution that works with industry-standard, display hardware. A feature of the SPx solution is that the application software is minimally affected by the introduction of radar video onto the display. This means that where third-party tooklits are being used, these can continue to provide the graphics, with radar video inserted intelligently as an intermediate layer.

SPx implements its layering using the standard window objects of the native graphics system (Microsoft Windows or X11).