Friday, January 28, 2011

DataBitray

Uploaded the bitmap handling component (which is endian independent thanks to FileBinary component) which reads bitmap files.

However the component I want to talk about is the DataBitray component (packages/data in SVN). It allows compression and decompression of pixel buffers with some nice features:
1. In-place compression/decompression - Because the compressed data is always smaller or equal to the original data, compression can be done in place. Decompression is done backwards which also allows it to be done in-place. This allows to save the number of buffers needed for compression/decompression.

2. No header overhead - The Bitray compression is based on RLE but without the header problem. Pixels of the same value are compressed into two integers. So one pixel is one pixel, two or more pixels of the same value are always 2 pixels wide.

3. Simple design - No complex hash arrays, it allows for great locality since no static variables are needed and because it does in-place compression/decompression it only requires the buffer itself to be in the cpu cache, not two buffers.

4. Small output - A display filled with a single color is 8 bytes long. If each row has a single color, it is 8 bytes multiplied by the number of rows. This works well for user interface elements since they tend to have pixels of the same value.

5. Small code - The entire DataBitray component is less than 150 lines of code including comments! Its easy to implement and easy to read.

I plan to write soon DataBitrayPaint which will allow to do the alpha-blending on the target buffer instead of just overwriting the buffer when decompressing the data. The step after that is writing a component to manage the data-bitray buffers for images, so they can be easily embedded into the application without relying on file i/o. The idea is to isolate platform dependencies and this will be one way to avoid a platform dependency for simple user interface images.

No comments: