One of the aims of ROWS is to be portable to other architechtures. This has a slightly unfortunate side-effect: we cannot use the built-in bitmap format of the underlying graphics system, as the bitmap may be plotted on other drawable types supported by ROWS (such as a printer). There are two ways of doing this: the first is something similar to the XImage structure, with all its restrictions, and the second is the one I have implemented and describe here.
ROWS provides the structures and routines for a device independant bitmap format. This is stored in client memory (on systems that have a client/server architechture such as X), and translated for plotting. The format contains information on the colour depth, pixel size, etc, and any bitmap can be plotted on any device - that's what device independant means. The drawables themselves provide suitable conversion mechanisms, and can take advantage of those already provided by ROWS. The ROWS abstract drawable will have to be implemented in the library in order to support drawing on the bitmaps.
The ROWS DIB is not intended for data interchange, and so its byte ordering is the same as the host's byte ordering. A bitmap is made up of several lines, each aligned to the size of an int32, each of which contains a list of pixels. Although this structure is represented as an int32 array, an individual pixel may only take up part of word. Where this occurs, the pixels are packed into the words as tightly as possible (for a 24bpp image, this means that there are 8 bits of padding after the pixel data, and for a 15bpp one, there is 1 bit of padding). In a word, the leftmost pixel begins at bit 0, and the rightmost ends at bit 31. For truecolour (15bpp and 24bpp) images, image data consists of RGB tuples. Red is always in the least significant bits, and blue in the most. For all other formats, pixel colour is discovered by looking up its value in a palette.
Still, if you want to know the disadvantages of the other approach, just have a look at the XImage structure...