Microsoft KB Archive/75214

{|
 * width="100%"|

INFO: Using RLE Bitmaps for Animation Applications In Windows

 * }

Q75214

-

The information in this article applies to:


 * Microsoft Windows Software Development Kit (SDK) versions 3.1, 3.0
 * Microsoft Win32 Application Programming Interface (API), used with:
 * Microsoft Windows NT Server versions 3.5, 3.51
 * Microsoft Windows NT Workstation versions 3.5, 3.51
 * Microsoft Windows 95

-

SUMMARY
Animation that uses a &quot;brute-force&quot; animation scheme, displaying successive complete bitmaps, can be slow and choppy. The alternative approach, displaying an initial frame and then modifying the elements that change, can save a great deal of time, memory, and disk space.

MORE INFORMATION
Animation applications typically use a very simple algorithm to display a sequence of bitmaps, or frames, one right over another, on the same display surface. When the application stores an entire frame in the device-independent bitmap (DIB) format, it suffers from three particular bottlenecks:


 * 1) With large frames or long sequences, the storage file becomes quite large.
 * 2) Loading an entire sequence requires a large amount of memory.
 * 3) Available Windows functions, such as BitBlt or SetDIBitsToDevice, may be too slow to animate the sequence smoothly.

For an animation sequence of bitmaps with a consistent set of colors, preprocessing the animation sequence and storing it in the run-length- encoded (RLE) format enables an application to run faster with a smaller storage file and memory requirement. Note that this RLE file is different from an RLE compressed DIB. This RLE format consists of several frames that are compressed according to the differences between frames. This process is straightforward and consists of five steps:


 * 1) Select the first frame in the sequence and store it in the DIB format.
 * 2) Compare the DIB bitmaps of consecutive frames. Due to the nature of animation sequences, the number of differences is often quite small compared to the size of the entire frame.
 * 3) Encode the set of changed pixels into RLE format. The encoded frame will contain information only on the pixels that change, the delta records will skip the unchanged pixels. The RLE bitmap is stored instead of the latter frame. For example, the RLE-encoded difference between the first and second frames is stored as the second frame.
 * 4) When the entire sequence is preprocessed, bring each frame into the system as a BITMAPINFO structure and stream of bits. Since only the first frame is in the DIB format, the memory requirement is quite low. Moreover, frames that contain an identical set of colors can share the BITMAPINFO structure, only the biCompression and biSizeImage fields must be changed.
 * 5) At display time, load the first frame as a DIB. Then use the SetDIBitsToDevice function to display subsequent frames in the sequence. Because this function requires much less information, the sequence can be animated much more quickly and smoothly.

Additional query words: 3.00 3.10 3.50 4.00 rle win16sdk

Keywords :

Issue type : kbinfo

Technology : kbAudDeveloper kbSDKSearch kbWin32sSearch kbWin32API kbWinSDKSearch