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

[Alex Bligh <alex@xxxxxxxxxxx>]

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