[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: Alex Bligh <alex@xxxxxxxxxxx>
- Date: Sat, 17 Jun 2006 10:16:44 +0100
- 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.