Memory Storage Types for Bitmaps

There are several types of bitmaps:

Conventional bitmaps: The most common bitmaps - support all bits/pixel and with the fastest access time. But they also require the highest amount of memory.
Compressed bitmaps: 1-bit only, using a proprietary RLE compression. They usually require less memory than the conventional bitmaps.
Super-Compressed bitmaps: 1-bit (uses Fax G4 compression), 8-bit, or 24-bit (uses MCMP compression) only. They require little memory but the read and write operations performed on the bitmap are slower. Also, the 8-bit and 24-bit compression is lossy, which means there is some small amount of degradation each the 24-bit super-compressed bitmap changes. (The 1-bit super-compressed bitmap uses lossless compression, so there is never any quality loss).
Disk bitmaps: all the bitmap data is on disk. But a memory view is used to access the disk, which causes more and more conventional memory to be used the as you read or write more bitmap pixels.
Tiled bitmaps: the bitmap is broken into separate tiles. Tiles can be disk or conventional memory.

You can specify the type of bitmap you want when you call LBitmapBase::Create or LBitmapBase::Allocate. You can also instruct LEADTOOLS to react dynamically depending on the bitmap size or the amount of available memory using LMemoryFile::SetMemoryThresholds.

When LEADTOOLS has to allocate a conventional bitmap, it does the following:

If the size of the bitmap being allocated is less than the fixed tile size (set through LMemoryFile::SetMemoryThresholds when uTileSize is > 0), the bitmap is allocated as conventional. If the allocation fails, the memory allocation function fails. If the allocation succeeds, the memory allocation function returns SUCCESS. No other steps are executed.
Checks the maximum size for a conventional bitmap (set through LMemoryFile::SetMemoryThresholds). If the size of the bitmap being allocated is greater than this threshold, a tiled bitmap will be allocated. Go to step 5. If the size of the bitmap being allocated is lower than the threshold, go to step 3.
Checks whether there is enough available memory to allocate a conventional bitmap. (This threshold is also set through LMemoryFile::SetMemoryThresholds). If there is not enough free memory, a tiled bitmap will be allocated and go to step 5. Else, go to step 4.
Try to allocate a conventional memory bitmap (bitmap which is contained entirely in conventional memory. If the allocation succeeds, the memory allocation returns success and no other steps are performed. If the allocation fails, go to step 5.
Try to allocate a tiled bitmap. There can be a mix of disk and conventional memory tiles. If the function succeeds, the allocation function returns success and no other steps are performed. If the allocation fails, go to step 6.
Try to allocate a tiled bitmap. Return success if the allocation succeeds, error otherwise.

To get the memory threshold information set by LMemoryFile::SetMemoryThresholds, call LMemoryFile::GetMemoryThresholds.

By default, the Windows temporary directory is used to store the disk files used for the disk tiles and disk images. You can change the location where these files are stored using LFileSettings::SetTempDirectory. You can get the current location using LFileSettings::GetTempDirectory.

Even when you have lots of RAM and enough space in the swap file, Windows might fail to allocate you one contiguous chunk of conventional memory. In this case, the bitmap will be allocated as tiled or disk.

Example: You attempt to allocate a 512MB bitmap. Windows might fail to allocate a contiguous 512MB memory chunk, but it might be able to allocate you 2x 256 MB chunks or 4x 128 MB chunks. In this case, LEADTOOLS allocates your 512MB bitmap using several smaller chunks in a tiled bitmap.

In a more extreme case, you might have not enough space to allocate the whole bitmap in conventional memory. Or you might have specified a maximum amount of conventional memory to be used with a bitmap. In either of these cases, LEADTOOLS will try to allocate a tiled bitmap with some tiles in conventional memory and others on disk.

The conventional memory tiles are always accessible (read further to see why this matters). Disk tiles will still need some chunks of conventional memory to read from disk/write to disk. We will refer to these chunks as "views". The more views you have, the more disk tiles can be accessed at a time and the faster the working with the bitmap will be. When you read or read from a disk tile, data is being cached to the view and no disk access is performed unless you move to another tile. The "move to another tile" operation is performed automatically when you read or write data to a certain row.

When you go to a disk tile that has no view, LEADTOOLS will:

create a new "view" (if you have not exceeded the maximum allowed of views and you have available memory) or
discard an old view and reassign it to the new tile. When the old view is discarded, data is written to the disk (if it has been modified since it was read). The writing of data to disk will cause a performance hit.

You can find out the memory allocation parameters for a bitmap using LMemoryFile::GetBitmapMemoryInfo. You can change the memory allocation parameters using LMemoryFile::SetBitmapMemoryInfo. The memory parameters are:

The memory type (conv, tiled, disk, etc)

These are for tiled bitmaps only:

The number of tiles
The tile size
The number of tiles in conventional memory
The maximum number of tile views in the conventional memory (for disk tiles only)
The number of tile views in the conventional memory (for disk tiles only)

Memory Storage Types for Bitmaps

See Also