[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 Gerry Iles
> Sent: 16 June 2006 17:01
> To: dev@xxxxxxxxxxxxxx
> Subject: RE: [XaraXtreme-dev] Debugging 
> View::RenderOptimalView - request for assistance
> 
> It certainly does sound like there are more byte order swaps 
> going on than necessary and in some circumstances the wrong 
> number of swaps are occurring.
> 
> I believe that the CWxBitmap class should always store the 
> pixel data in exactly the same format regardless of platform. 
>  Our kernel representation of a 32bpp rgba pixel is a struct 
> containing 4 bytes, and, for maximum efficiency, I think this 
> should be maintained in the oil class so the first byte of 
> the pixel data should always be the red component.  For other 
> depth bitmaps (16bpp and 24bpp), the same principal should apply.

I agree but CWxBitmap is an OIL class, implying that it should be
allowed to adapt to the native platform if required. I.e. /if/ its data
is ever sent directly to wxWidgets and /if/ wxWidgets requires the bytes
in a particular order then it's obviously more efficient to store the
bytes that way.
I use those "/if/"s because:
A. CWxBitmaps are mainly rendered by CDraw, not wxWidgets, and
B. It's hard to believe wxWidgets would allow it's bitmap format to
change on different platforms - that's /exactly/ the sort of thing it
should be protecting us from!

> 
> What do other things do?  E.g. when loading a png using 
> libpng, does the scanline data passed to the app vary with endianness?
> 
> Is the CDraw pixel format consistent across byte ordering in this way?

Gavin told me that CDraw swaps RGB byte order internally using the same
Windows/Linux conditional compilation as we see in LX.

> 
> The code that initialises a CWxBitmap (e.g. when loading 
> bitmaps), code that creates other types of bitmap (e.g. a 
> wxBitmap) from a CWxBitmap and any code that treats the 
> pixels as (U)INT32s will need to be careful about byte order.

Yes, and having it be the same storage format on all platforms would be
a major help with that!

I half suspect a chicken and egg thing has gone on here - LX stores
bitmap data differently on the two platforms because CDraw requires it
and CDraw only requires it because LX stores it that way...?

Phil