Keiron Liddle wrote:
> Mark did changes in two areas.
> He made it so that once a page is rendered it can be output to the
> stream immediately.
> The other part that he changed was to do the layout then render after
> the end of a page sequence with a bit less coupling between the page
> sequences in the fo tree.

He did a few other minor changes, which have some non-trivial
One of them was to move references to generated areas from
instance variables to local variables in the layout() routines
and remove some back references and perhaps other similar stuff.
The other was not to add page sequences to root as children
(thereby introducing a few minor bugs).
The first means that the area objects can be GC'd after
the page is removed from the rendering queue. There will
still some area objects hang around, namely those referenced
by link sets, but most can be reclaimed. This is where the
"do not use forward references" comes mainly from, and this
was *the* improvement regarding reduced memory consumption.
The second means that the FO subtree of the page sequence
can be reclaimed after it has been streamed to the renderer,
(if there weren't the generated-by back pointer, even if the
page was still in the rendering queue). This is where the
"use multiple page sequences" comes from.
Mark also removed the BufferManager which caused text nodes
to stick around forever.

As for the redesigned code, FOs appear to refer to layout
managers, which in turn refer to areas. Unless it is somewhere
ensured that either areas are properly removed from managers
and/or managers are removed from the FO, the possible early GC
of area objects is undone.
It also seems to me that a lot more small objects are
used, which is also bad for peak memory consumption.
Of course, this is based on a somewhat cursory code examination
rather than exact measurements.

Ok so far.

One of the bigger problems is that objects holding FO property
values are much more abundantly created than necessary. For
example, to "franklin_2pageseqs" sample produces more than
hundred FontState instances, while only three different are
really necessary. While there may be attempts to solve this
in the redesign, they are not yet recognizable.

> Again I
> have taken this idea a step further and the plan is to render at the end
> of a page and then throw away the contents of the page and the fo tree.

This could turn out to be a bad idea in case orphans/widows or
the infamous "last page master" and perhaps footnote reshuffling
or reconsidering break preferences cause the last page to be
rerendered. Note that either of these could have an unpleasant
rippling effect through previous pages. I think it is only really
safe to get rid of FOs at page sequence boundaries and perhaps
forced page breaks.


To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to