[Date Prev][Date Next][Thread Prev][Thread Next][Thread Index]
[XaraXtreme-dev] RE: Bitmap storage format [Was: Debugging View::RenderOptimalView - request for assistance]
- From: "Phil Martin" <Phil@xxxxxxxx>
- Date: Fri, 16 Jun 2006 17:22:41 +0100
- Subject: [XaraXtreme-dev] RE: Bitmap storage format [Was: Debugging View::RenderOptimalView - request for assistance]
> -----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...?