[Date Prev][Date Next][Thread Prev][Thread Next][Thread Index]
Re: [XaraXtreme-dev] RE: Bitmap storage format [Was: Debugging View::RenderOptimalView - request for assistance]
- From: Alex Bligh <alex@xxxxxxxxxxx>
- Date: Fri, 16 Jun 2006 20:13:53 +0100
- Subject: Re: [XaraXtreme-dev] RE: Bitmap storage format [Was: Debugging View::RenderOptimalView - request for assistance]
Phil Martin wrote:
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"...
Well I think that is probably the bug! I don't know /why/ the bitmap
format is not in straight DIB format (at least for architectures
of the same endianness).
Maybe the reason is that blitting the CDraw output bitmap requires a
different RGB byte order on Linux and the byte order percolates back
I'm not sure why that would be. At least on the current plotting
route (USE_wxBITMAP == 0) we process Gavin's output buffer word
by word anyway (we OR in 0xff00000 as GTK expects ff for an
alpha value). We could just as easily swap R and B if they are
the other way around in a DIB from GTK (I'm not sure they are).
My point is that the Linux RGB byte order does not (certainly
need not) drive it. The only thing I can see might need to
change is the CONVHINT stuff which seems to presume a fixed
RGB order in the final output format.
I would have thought the least bug ridden way forward would be
"use DIB format everywhere". How would people feel about that?