3. CVNView Logistics

As mentioned above, a class consists of approximately 210 slides, all of which are formatted as 448*336 pixels at 24 bit color. Several of CVNView's features use the image information of all 210 slides; some features require the original image data, others require transparent image data. Moreover, the image data needs to be ready and loaded as quickly as possible. To this effect, the best way to quickly access the image data is to

1. keep all of the image data in memory in its uncompressed form, and
2. keep a copy of each slide in memory in its transparent form.

For that reason, all 210 slides must be loaded into memory (without using slow swap space), where each slide appears in two different versions. For uncompressed data, this would require:

• 24 bits per image (RGB) for 210 slides: 448*336*24*210 bits = 448*336*3*210 bytes = 90.45 Mb
• 32 bits per image (ARGB) for 210 slides: 448*336*32*210 bits = 448*336*4*210 bytes = 120.59 Mb

= 211.03 Mb of memory for only image data. Figuring in the overhead of creating image objects, and the memory requirements for CVNView itself (using offscreen images for double buffering), this number can grow to 240 Mb.

Even though CVNView works best in memory-resident mode, it does provide a means to be used without such high memory requirements. In this version, the compressed JPEG data is loaded into memory only once. The average size for a 448*336 pixel * 24 bit image is around 35Kb. For 210 images, the memory requirements for raw image data would then be:

• all images: 210*35Kb = 7.18 Mb

Figuring in the overhead, we may end up with below 50 Mb of memory usage altogether. This memory-non-resident version of CVNView will, however, run much slower, as for each image data access, the data must first be decompressed, and then be translated into its transparent format. This introduces a noticeable increase in CPU usage and is not recommended.