Hi, We plug batik into our system as a java bean to view our svg documents. And we still have out of memory problem.
It can be reproduced by using batik svgbrowser as follows. 1) Open batik browser window. 2) go to http://cec.wustl.edu/~jl2/sample.svg 3) reload 4) reload 5) out of memory I have some memory usage statistics here (read from memory monitor in tools) Memory Usage open batik browser 5,500 k http://cec.wustl.edu/~jl2/sample.svg 22,000 k reload 51,000 k reload out of memory If I manually do garbage collection in between each step, I got Memory Usage open batik browser 5,000 k http://cec.wustl.edu/~jl2/sample.svg 22,700 k garbage collect 22,000 k reload 58,000 k garbage collect 39,900 k reload out of memory In our system, we use JScrollPane to hold the svgCanvas, so that when we zoom, we still see the whole picture. I added a JScrollPane in batik browser by making a tiny change to JSVGViewerFrame.java JScrollPane myScrollPane = new JScrollPane(svgCanvas); myScrollPane.setPreferredSize(new Dimension(800, 800)); p2.add(myScrollPane, BorderLayout.CENTER); //p2.add(svgCanvas, BorderLayout.CENTER); p = new JPanel(new BorderLayout()); p.add(p2, BorderLayout.CENTER); p.add(statusBar = new StatusBar(), BorderLayout.SOUTH); Then I found I could run out of the memory even quicker Memory Usage open batik browser 13,000 k http://cec.wustl.edu/~jl2/sample.svg 46,000 k reload out of memory and with garbage collection in between, Memory Usage open batik browser 13,000 k http://cec.wustl.edu/~jl2/sample.svg 47,000 k garbage collect 37,000 k reload out of memory I think the problem comes from the viewbox attribute in svg file. When the width and height is very big, it taks a lot of memory to display. Since our system requires the user should be able to see the whole picture of the enlarged svg file, we'll have to set the big width and height accordingly. Doing manually garbage collection does help a bit. In /org/apache/batik/apps/svgbrowser/Main.java, I also see garbage collection at the end of the rendering. c.addGVTTreeRendererListener(new GVTTreeRendererAdapter() { public void gvtRenderingCompleted(GVTTreeRendererEvent e) { initDialog.dispose(); v.dispose(); System.gc(); run(); } }); Doesn't it seem like the memory leak problem is still out there? Thanks! Jenny --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]