J.Pietschmann wrote:
I suspect this is be cause row and cell areas are referenced from their corresponding FOs itself and are therefore kept in memory together with all their descendants until the page sequence is completely rendered (in contrast to all other area objects which are reclaimed after a page is rendered). There is a fix for this in CVS.
I have now made a comparison between 0.20.5 and the latest maintainance code in CVS, and I do not see the effects described above. I have tested with the sample AWT-previewer in FOP, and found that the memory footprint are very similar, but I will now check in the actual environment. Do I need to provide some configuration parameters which may change the behaviour of FOP?
To clarify what I currently need to render, I would have attached a sample FO-file but this is not accepted on the list. Interested parties may have a look at http://unixsnedkeren.dk/fop/t2.zip. Suggestions are appreciated. We are considering redesigning this to avoid using tables so much, but if better performance can be achieved with what we have, that would be nice. Basically the JVM in which this runs, has a very large heap and little CPU to spare, and spends much too much time garbage collecting, as well as take quite a while in rendering.
By accident I first checked with the code in HEAD, which did not work well, so I am convinced that 1.0 is still some time away :)
-- Thorbjoern Ravn Andersen "...plus...Tubular Bells!"
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
