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

["Gerry Iles" <GerryI@xxxxxxxx>]

Oh yeah, there are also these two defines at the top of view.cpp

#ifdef _DEBUG
//	#define _DEBUG_ATTACH_OPTIMAL_BITMAP
//	#define _DEBUG_ATTACH_OPTIMAL_MASK
#endif

If you define these then the bitmaps for each complex span will get
added to the document and can be examined in the bitmap gallery (and
dragged into the document etc).

Gerry

-----Original Message-----
From: owner-dev@xxxxxxxxxxxxxxxx [mailto:owner-dev@xxxxxxxxxxxxxxxx] On
Behalf Of Gerry Iles
Sent: 15 June 2006 09:46
To: dev@xxxxxxxxxxxxxx
Subject: RE: [XaraXtreme-dev] Debugging View::RenderOptimalView -
request for assistance

If you are getting no transparent stuff output during RenderSimpleView
then there must be something wrong.  What it should do is render all of
the document from the bottom up to the top most complex object into a
bitmap and then render all the on top, non-complex stuff normally.  E.g.
where everything is non-complex then it just renders normally but if you
have one transparent object on the top then the whole document should
render into a bitmap.

When I was rewriting RenderOptimalView (and RenderSimpleView) to use
RenderTree rather than the old tree scanning methods I found that the
easiest way to debug it was to stick lots of trace in it (it should
still be there) and print simple documents to a file using a normal PS
driver and then use GhostScript to look at the results.  This could be
single stepped as required.  Since you are doing EPS export then you
should be able to do the same.

If you look at DocView::ContinueRenderView you will see that when
viewing a separation it uses RenderSimpleView.  You could just force
this function to call RenderOptimalView all the time but I suspect the
output would get a bit confusing for sensible debugging.  I seem to
recall there were some problems using it on screen though it may have
just been that it was too slow for decent on screen performance.  You
will probably be better off simply single stepping through the
RenderOptimalView code.

There is a useful function called DumpNodeRuns in the
ScanningRenderRegion that may tell you useful things (e.g. the
ScanningRenderRegion isn't managing to actually create any node runs).
Since chunks of the doc go missing I assume that there are node runs
being generated.  RenderOptimalBitmapPhase gets called from the
OptimalPrintRenderCallback class to render the complex node runs so put
some trace back in there too.

The most likely problem is either in the creation of the bitmaps for the
complex spans or in the rendering of those bitmaps to the main render
region.  There is a special function used to render the bitmaps using
the mask (that is also generated) and I suspect that this function isn't
correct.

Like I say, the easiest way is probably to create some simple docs with
just a few objects (e.g. rectangle, trans rectangle, rectangle) and see
what happens.

Gerry

-----Original Message-----
From: owner-dev@xxxxxxxxxxxxxxxx [mailto:owner-dev@xxxxxxxxxxxxxxxx] On
Behalf Of Alex Bligh
Sent: 14 June 2006 20:46
To: xara-dev
Cc: Alex Bligh
Subject: [XaraXtreme-dev] Debugging View::RenderOptimalView - request
for assistance

I am (attempting) to debug by EPS export stuff, which uses
View::RenderOptimalView() to decide which bits to print as
a bitmap and which to print as postscript. If I just use
simple mode, I get an output, albeit one without transparency.
Now I have reenabled thie OptimalView stuff I get far less
output (but still clearly the right document).

What is the best way to go about debugging this stuff? Is
there (for instance) some secret-squirrel control to make
the normal (displayed) view use OptimalView instead (i.e.
render stuff into subsidiary bitmaps etc.)? Any hints?

Alex