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

["Phil Martin" <Phil@xxxxxxxx>]

CWxBitmap doesn't seem to have much connection to wxWidgets at all, no.
The only thing is a function called MakewxImage which runs through the
bitmap pixel by pixel anyway and so may as well swap the RGB byte order
there if need be.

BUT, for some reason its RGB byte order on Linux is different than on
Windows and so it's probably not correct to call that "DIB format"...

Maybe the reason is that blitting the CDraw output bitmap requires a
different RGB byte order on Linux and the byte order percolates back
from there?

Phil 

> -----Original Message-----
> From: owner-dev@xxxxxxxxxxxxxxxx 
> [mailto:owner-dev@xxxxxxxxxxxxxxxx] On Behalf Of Alex Bligh
> Sent: 16 June 2006 17:27
> To: dev@xxxxxxxxxxxxxx
> Cc: Alex Bligh
> Subject: Re: [XaraXtreme-dev] RE: Bitmap storage format [Was: 
> Debugging View::RenderOptimalView - request for assistance]
> 
> I don't think CWxBitmap does not contains any wxWidgets bitmap format.
> I'm pretty sure it's in DIB format. That's unless someone has 
> managed to persuade wxBitmap raw write code to use it for blitting.
> 
> Alex
> 
> --On 16 June 2006 17:22 +0100 Phil Martin <Phil@xxxxxxxx> wrote:
> 
> >> -----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
> >
> >
> 
> 
> 
> Alex
>