You are viewing a plain text version of this content. The canonical link for it is here.
Posted to batik-dev@xmlgraphics.apache.org by Jenny Liu <jx...@bjc.org> on 2001/12/20 00:42:32 UTC
out of memory problem
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: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org
Re: out of memory problem
Posted by Thierry Kormann <tk...@ilog.fr>.
On Thursday 20 December 2001 00:42, Jenny Liu wrote:
> 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.
OK, so there are several things to say.
[A]
The good news is that batik does *not* have a memory leak. You can load again
and again your document in our browser.
[B] Your document is big (2600x2000). The JSVGCanvas by default automatically
adapts its size to the size of the document. So the first time, the offsceen
image we create is 2600x2000 big.
Then when you change documents (or reload for example), if the double
buffering option is activated - the first image is kept until the new
document is finished (so 2 big images are in memory - during that phase only
but that's enough to go to OutOfMemoryException).
[C] The JScrollPane is not the proper way to add scrollbar to the canvas
because the JScrollPabe sets to its enclosed component its preferred size
(which is the size of the SVG document in our case).
You should consider subclassing the JSVGCanvas and implement the
javax.swing.Scrollable interface (or see our the MVC works with scrollbar in
swing) to pan when you use scrollbar (instead of scrolling on a big buffered
image).
[D] If you grow the memory of the VM (using -X... options), you should be
able to reload your document as many times you want.
Hope that helps.
Thierry.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org
Re: out of memory problem
Posted by Vincent Hardy <vi...@sun.com>.
Jenny,
I have tried to reproduce the problem with:
http://cec.wustl.edu/~jl2/sample.svg
with 1.1.1 and I am not able to get an OutOfMemoryException. Did you
get this with 1.1 or with 1.1.1?
Vincent.
Jenny Liu wrote:
>
> 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: batik-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: batik-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org