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

["Phil Martin" <Phil@xxxxxxxx>]

> -----Original Message-----
> From: owner-dev@xxxxxxxxxxxxxxxx 
> [mailto:owner-dev@xxxxxxxxxxxxxxxx] On Behalf Of Alex Bligh
> Sent: 17 June 2006 00:20
> To: dev@xxxxxxxxxxxxxx
> 
> Phil,
> 
> >> I would have thought the least bug ridden way forward 
> would be "use 
> >> DIB format everywhere". How would people feel about that?
> >>
> >
> > Absolutely. It would be good to hear Luke and Gavin's 
> comments about 
> > this first, though.
> 
> We ought also to take the opportunity of defining the byte 
> order in bigendian patforms. IE does it have the same 32bit 
> quantities as on a little-endian paltform, or does it hold 
> the bytes in the same order?
> My preference is for the latter though here we should ask 
> Gavin what he does.
> 
> And then we ought to write the answer down, define it as 
> "Camelot internal bitmap format" and enforce it everywhere.
> 
> Alex [who thinks there is a distinct irony in supporting 
> maintaining DIB
>       format in a Linux app]
> 

I agree that we should hold the bytes in the same order on
little/big-endian platforms because we should be treating an RGB pixel
as a struct not a UINT32. That way we could remove a whole bunch of
assumptions from the code. (And help prepare the code for 64BPP or
floating point pixels? Or worse, CMYK pixels???).

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...

Phil