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 effects. 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. J.Pietschmann --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
