RE: [XaraXtreme-dev] Debugging View::RenderOptimalView - request for assistance

["Gerry Iles" <GerryI@xxxxxxxx>]

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.

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?

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.

Gerry

-----Original Message-----
From: owner-dev@xxxxxxxxxxxxxxxx [mailto:owner-dev@xxxxxxxxxxxxxxxx] On
Behalf Of Phil Martin
Sent: 16 June 2006 16:13
To: dev@xxxxxxxxxxxxxx
Subject: RE: [XaraXtreme-dev] Debugging View::RenderOptimalView -
request for assistance

Note that LX's CWxBitmap class stores 24BPP (32BPP?) bitmap data in
different orders depending whether it's running on Linux or Windows (and
the poor old Mac, with it's own byte ordering problems, is an unknown
factor in this area).

That means that when we load bitmaps from XAR files, for instance,
there's conditional code to flip the byte order around. Similar code
exists in several places (and possibly in CDraw itself!).

I have to say I'm not really happy about this (and I fear there might be
paths that swap the byte to and fro a number of times). I'd prefer the
code to be transparent to this but I haven't been able to work out why
this byte order reversal happens or whether it's practical to change it.

Phil 

> -----Original Message-----
> From: owner-dev@xxxxxxxxxxxxxxxx 
> [mailto:owner-dev@xxxxxxxxxxxxxxxx] On Behalf Of Gerry Iles
> Sent: 16 June 2006 15:53
> To: dev@xxxxxxxxxxxxxx
> Subject: RE: [XaraXtreme-dev] Debugging 
> View::RenderOptimalView - request for assistance
> 
> I've just tested this after adding the ScopedFlagSetter line 
> below and it now seems to export EPS properly.  Well, like 
> you said, the RGB order seems to be wrong and my document is 
> displaying rotated 90 degrees in KGhostview, but the 
> simple/complex handling seems to be working fine.
> 
> I've checked in the tweak...
> 
> Gerry
> 
> -----Original Message-----
> From: owner-dev@xxxxxxxxxxxxxxxx 
> [mailto:owner-dev@xxxxxxxxxxxxxxxx] On Behalf Of Gerry Iles
> Sent: 16 June 2006 15:43
> To: dev@xxxxxxxxxxxxxx
> Subject: RE: [XaraXtreme-dev] Debugging 
> View::RenderOptimalView - request for assistance
> 
> > Turning off caching at the global level (from the Debug menu) would 
> > simplify your testing.
> 
> As well as instantly confirming whether this is, in fact, the 
> problem...
> 
> > There are places where the caching is disabled within the 
> scope of a 
> > function using a "ScopedFlagSetter".
> 
> It appears that there should be this line at the top of 
> Filter::ExportRender
> 
> ScopedFlagSetter
> fsBitmapCacheing(NodeRenderableBounded::bEnableCacheing, FALSE);
> 
> That is in the current Xtreme code but not in XaraLX...
> 
> Gerry
>