Optimizing the User Experience of 24-bit AWIPS Rendering

Michael Biere

9 October 2002

The Problem

There are a number of image-processing operations in AWIPS which appear noticeably slower on a modern 24-bit true-color display than they were on previous 8-bit pseudo-color displays. Examples include image brightness adjustment and fade between combo images.

These operations were implemented as color table changes on the 8-bit hardware, which involves modifying at most a few thousand bytes of memory in a display card. With a 24-bit display these pseudo-color table tricks are no longer valid, and the resulting images must be re-rendered pixel by pixel, which typically involves modifying millons of bytes of display memory. The result is that the volume of data to be rendered overwhelms the improvement in display speed, resulting in an apparent degradation of performance. These differences are intrinsic to 24-bit displays, and it is unlikely that algorithmic improvements to the image-processing algorithms will improve things dramatically.

The Solution

All is not lost, however. There are changes elsewhere that should produce the desired improvement. In fact, the rendering of a single frame of imagery is not likely to be noticeably worse to the user under these circumstances. The main factor which contributes to the degraded user experience is the simplistic coupling between the existing user interface (typically a slider bar) and the rendering engine (the IGC). Well-known techniques for enhancing this coupling exist, involving look-ahead in the event queue. These techniques avoiding rendering intermediate frames when the user is changing the user interface faster than the rendering engine can keep up. The end result is a much more responsive user experience. In my opinion, these changes would be sufficient to make 24-bit rendering appear essentially as fast as the 8-bit pseudo-color case.

The Proposal

I propose that FSL investigate the use of event queue lookahead to resolve the perceived slowness of certain 24-bit rendering operations, specifically brightness and fade. The required volume of code is likely to be low, perhaps a hundred LOC or so, but the event handling mechanisms in AWIPS are fairly involved, so the level or technical difficulty may be high. The simplest implementation would involve changes to the Tcl GUI only, but the most user-responsive implementation will probably require IGC event handling modifications (possibly involving lookahead extensions to the ThreadIPC). In the worst case, changes in the interaction between the IGC and the Tcl GUI might be required, although that is unlikely.

The Estimate

This is probably a 6-8 week effort including support functions.

The Risks

There is a high probability of success. Event lookahead algorithms are fairly simple in principle. The only risk I see is if the interfaces to the current event-handling or threadIPC code are so complex or subtle that the code development time is longer than expected.