[Date Prev][Date Next][Thread Prev][Thread Next][Thread Index]
RE: [XaraXtreme-dev] RE: Bitmap storage format [Was: Debugging View::RenderOptimalView - request for assistance]
- From: "Gerry Iles" <GerryI@xxxxxxxx>
- Date: Sat, 17 Jun 2006 13:39:54 +0100
- Subject: RE: [XaraXtreme-dev] RE: Bitmap storage format [Was: Debugging View::RenderOptimalView - request for assistance]
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
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
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
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.
From: owner-dev@xxxxxxxxxxxxxxxx [mailto:owner-dev@xxxxxxxxxxxxxxxx] On
Behalf Of Alex Bligh
Sent: 17 June 2006 10:17
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
> 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
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
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
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
format, I don't see why we shouldn't store bitmaps in that format. So
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.