[Date Prev][Date Next][Thread Prev][Thread Next][Thread Index]

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.


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