RE: [XaraXtreme-dev] RE: Bitmap storage format [Was: Debugging View::RenderOptimalView - request for assistance]

["Gerry Iles" <GerryI@xxxxxxxx>]

I agree, as I said earlier, that we should always use the same byte
order (e.g. the first byte of a 32bpp bitmap should always be the red
component).

Out of interest, does anyone know what happens with DIBs in NT on MIPS
or PowerPC...?  I.e. is the byte order different or not?  If the byte
order does vary with endianness then we should probably make it do so
too (even if this causes us more work).

The OilBitmap class is defined in the kernel because it defines what
kernel code can do to a bitmap.  We should still have an OilBitmap
derived class in the oil layer as it can then implement additional
functions that are specific to use from the oil layer (e.g. MakewxBitmap
etc).

Kernel code, when scanning through pixels, is supposed to call a
function that extracts a scanline as an array of Pixel32bpp structs.
Any code that does directly scan through the bitmap bits defined by the
underlying oil bitmap derived class should only exist in the oil layer.

Personally, I think the kernel/oil bitmap split has been over-engineered
and the precise format of the bitmap bits could have been specified by
the kernel which would probably have simplified a lot of the bitmap
handling code.

I agree that the name CWxBitmap is a bit confusing.  However it will
contain significantly different code to the original CWinBitmap class so
we probably should call it something else.

Gerry

-----Original Message-----
From: owner-dev@xxxxxxxxxxxxxxxx [mailto:owner-dev@xxxxxxxxxxxxxxxx] On
Behalf Of Alex Bligh
Sent: 17 June 2006 10:17
To: dev@xxxxxxxxxxxxxx
Cc: Alex Bligh
Subject: RE: [XaraXtreme-dev] RE: Bitmap storage format [Was: Debugging
View::RenderOptimalView - request for assistance]



--On 17 June 2006 09:51 +0100 Phil Martin <Phil@xxxxxxxx> wrote:

> We could also perhaps move CWxBitmap into the Kernel (with a bit of
> fiddling and a rename). If we are defining "DIB" as our internal
storage
> format on all platforms CWxBitmap ain't an Oil class any more...

Well I'd say we ought to define an internal bitmap format that looks
very
much like DIB, rather than actually *is* DIB. For a start, we don't use,
require, or set up all the required DIB fields, nor support all the DIB
variants (AFAIK). Also DIB is somewhat pointlessly limited to 4GB (just
by
the biSize field being 32 bit) which we need not be hindered by at least
for bitmap sources (yes I know CDraw won't support it right now).

I think in practice the chances of using a different internal bitmap
format
on different platforms is minimum. Half the kernel already looks through
the internal bitmap format (see for instance the masked rr stuff which
are now in the kernel). And if we store (say) paths in our own
non-platform
format, I don't see why we shouldn't store bitmaps in that format. So
yes
I agree we could then move stuff into the kernel. Bizarrely enough,
OilBitmap (though not CWxBitmap) is defined in the kernel.

I also recommend we do a global search and replace to change CWxBitmap
back to CWinBitmap not least because CWxBitmap sounds like something
derived from wxBitmap. It /is/ a windows (type) bitmap because it
is in DIB-esque format. Alternatively we could call it CamBitmap or
something, but CWxBitmap is just confusing.

Alex