@Piru
That's one of the reasons, amongst others. I like to be able to get things into device depentent format for rapid harware manipulation, especially blitting etc.
The code forms part of the graphics library code of my framework. I have a class "Surface" which specifically represents a rectangular pixel array in video ram. Under the amigaos implementation, this is an OS BitMap that is a friend of some existing visible BitMap, hence we have no real say it it's exact format.
Another class in the same library is "ImageBuffer", that simply encapsulates an array of pixel data that would typically be stored in normal memory and allow direct manipulation. The ImageBuffer class is in the common part of the source and hence does not encapsulate a BitMap, rather it just wraps a block of normal memory.
You can paint your ImageBuffer onto a Surface using Surface::putImageBuffer(image, sx, sy, ix, iy, w, h), where sx/sy = position on the Surface, ix/iy = position within ImageBuffer and w/h define the rectangle to draw.
An example application the above follows:
A simple paint demo built on the framework (
source code here), we have a canvas which is eg a 32-bit ARGB ImageBuffer. We draw on this and then paint the changed area onto a Surface obtained from our display.
Naturally, the latter is probably not in the same format as the former and the appropriate conversion happens when we call putImageBuffer().
It all works perfectly under CGX using the query methods and direct bitmap access. It also works under p96, the results are just screwed up :-(
-edit-
@Thomas
Incidentally, there is also Surface::putSurface() method that is used in the same way as the putImageBuffer(). This method does use BltBitMap() internally ;-)