DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=32354>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=32354 Summary: AWTRenderer fails with OutOfMemoryError when switching pages. Product: Fop Version: 0.20.5 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P3 Component: awt renderer AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] If you set a large scale factor say 400% on the AWTRenderer and render the first page it works but when switching to the next page it fails with an OutOfMemoryError. The problem is in the render(Page) method where it allocates a new BufferedImage and graphics. During the BufferedImage allocation the the previous pageImage and graphics can not be garbage collected because they are still referenced. Therefor it requires enough memory for two BufferedImages. This can be fixed by setting the pageImage and graphics variables to null before allocating a new BufferedImage. Also after the page has been rendered the graphics variable is not needed and can be garbage collected. Heres my proposed fix: public void render(Page page) throws IOException { pageImage = null; // do work ... graphics = null; } I checked the current CVS to see if this has been addressed but it now generates BufferedImages for each page and stores them in a bufferedImageList. This would surely require a large amount of memory! I personally prefer the Java2DHook style thing in the http://nagoya.apache.org/wiki/apachewiki.cgi?FOPAvalonization/AltAPIProposalJM where the user can supply the Graphics2D to render to so they can manage their own memory. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
