On Fri, 2002-08-09 at 19:06, J.Pietschmann wrote: > 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.
No. FOs create layout managers. Layout managers refer to FOs. Layout managers create areas. The only place that areas are held onto is the area tree. The page sequence layout manager holds onto the area tree to add pages. The area tree then handle how the pages are used. If a page is rendered then it is cleared. The layout managers can then release FOs that are done with and the areas are not held onto. I don't know where you get the idea that a lot of small objects are used. Remember it is not finished yet. Peak memory usage should be: largest image currently loaded temporarily + at least one fo block (but not much more) + one page area + render stuff + common (static pagination) areas. A bit hard to define but I am certain the result will be less memory. > 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. Does that mean we should not attempt to solve this problem? Or that we should attempt to solve the problem twice independantly. > 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. As far as I know there is never a case where a finished page should be redone. Once a page is complete that is it. Those problems should be solved during the layout of a page only and not considering furture pages. Keiron. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
