You are viewing a plain text version of this content. The canonical link for it is here.
Posted to batik-users@xmlgraphics.apache.org by Hans Stoessel <hs...@pm-medici.ch> on 2003/04/09 09:56:21 UTC
JSVGCanvas: java.lang.OutOfMemoryError
Hi
I use the following source code to display a svg file with a chart in a
dialog:
//--------------------------------------------------------------------------
// Init dialog
//--------------------------------------------------------------------------
private void jbInit() throws Exception {
// Border
Border oBorderLabel = new EmptyBorder(0, 0, 0, 10);
// Panel
m_oJPanelChart = new JPanel(new GridBagLayout());
m_oJPanelChart.setBorder(new TitledBorder(new EtchedBorder()));
// Constraints
GridBagConstraints c = new GridBagConstraints();
c.insets = new Insets(2, 2, 2, 2);
c.anchor = GridBagConstraints.WEST;
// SVG-File
JSVGCanvas svgCanvas = new JSVGCanvas();
// Set the JSVGCanvas listeners.
svgCanvas.addSVGDocumentLoaderListener(new SVGDocumentLoaderAdapter() {
public void documentLoadingStarted(SVGDocumentLoaderEvent e) {
m_oJTextFieldState.setText("SVG file is loading...");
}
public void documentLoadingCompleted(SVGDocumentLoaderEvent e) {
m_oJTextFieldState.setText("SVG file loaded...");
}
});
svgCanvas.addGVTTreeBuilderListener(new GVTTreeBuilderAdapter() {
public void gvtBuildStarted(GVTTreeBuilderEvent e) {
m_oJTextFieldState.setText("Chart is building...");
}
public void gvtBuildCompleted(GVTTreeBuilderEvent e) {
m_oJTextFieldState.setText("Chart builded...");
}
});
svgCanvas.addGVTTreeRendererListener(new GVTTreeRendererAdapter() {
public void gvtRenderingPrepare(GVTTreeRendererEvent e) {
m_oJTextFieldState.setText("Chart is displaying...");
}
public void gvtRenderingCompleted(GVTTreeRendererEvent e) {
m_oJTextFieldState.setText("");
m_oJPanelChart.remove(m_oJLabelState);
m_oJPanelChart.remove(m_oJTextFieldState);
m_oDialogChart.pack();
m_oDialogChart.centerWindow();
}
});
svgCanvas.setURI(new File("test.svg").toURL().toString());
c.gridx = 1;
c.gridy = 0;
c.gridwidth = 2;
m_oJPanelChart.add(svgCanvas, c);
// Label Schriftstil
c.gridx = 0;
c.gridy++;
c.gridwidth = 1;
m_oJLabelState = new JLabel("State:");
m_oJLabelState.setBorder(oBorderLabel);
m_oJPanelChart.add(m_oJLabelState, c);
// Textfeld Schriftstil
c.gridx++;
m_oJTextFieldState = new JTextField(30);
m_oJTextFieldState.setEnabled(false);
m_oJPanelChart.add(m_oJTextFieldState, c);
// Buttons
m_oButton = new PanelDialogChart_Button();
// Dialog bauen
JPanel oJPanel = new JPanel(new BorderLayout());
oJPanel.setBorder(new EmptyBorder(10, 10, 10, 10));
oJPanel.add(m_oJPanelChart, BorderLayout.CENTER);
oJPanel.add(m_oButton, BorderLayout.SOUTH);
setTitle("Chart);
getContentPane().add(oJPanel);
setResizable(false);
centerWindow();
}
If I do that a few times, then I have the java error:
java.lang.OutOfMemoryError <<no stack trace available>>
I use Batik 1.5 Beta 5 and Windows 2000. If I have a look in the task
manager of windows, I see that the memory is increasing with every time I
display a SVG file in my dialog.
What could be wrong?
Thanks for help
Hans
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: JSVGCanvas: java.lang.OutOfMemoryError
Posted by Thomas E Deweese <th...@kodak.com>.
>>>>> "HS" == Hans Stoessel <hs...@pm-medici.ch> writes:
HS> I try it with the memory monitor and the memory is increasing with
HS> every using of JSVGCanvas. And I can't reach a solid baseline if I
HS> call the carbage collector manially. I have a look to my code
HS> again and I don't think there is a reference dangling. Could it
HS> be, that is a problem with the SVG file? I can't imaging that, but
HS> I really don't know where I can find the memory leak...
Can you reproduce the memory leak by loading your SVG directly in
Squiggle? If so then send us the file (offline if large or you don't
want the world to see it). It is possible that your document has
something that triggers a large memory leak (i.e. holding a reference
to the document).
If you can't reproduce it this way then I still strongly suspect
your code :) Try creating a small app that just pops up your dialog
again and again. Get a real Java heap tool.
HS> Thanks
HS> Hans
HS> "Thomas E Deweese" <th...@kodak.com> schrieb im
HS> Newsbeitrag news:16020.12887.411199.423737@frog.rl.kodak.com...
>> >>>>> "HS" == Hans Stoessel <hs...@pm-medici.ch> writes:
>>
HS> I think its definitely a bug in JSVGCanvas. You can reproduce it
HS> with the application batik-squiggle who uses JSVGCanvas to display
HS> SVG files. If you open a SVG file in it and reload this file a few
HS> times, you see in the task manager of Windows 2000 how the memory
HS> is increasing...
>> Squiggle has a built in Memory monitor (with a GC button). When I
>> use that with say samples/mapSpain.svg I can load it dozens of
>> times and if I press collect two/three times the memory quickly
>> returns to a solid baseline. This is even true for 3d.svg (dyanmic
>> document) - it actually has a lower baseline since we cache lots of
>> image data for static documents.
>>
>> We do not sprinkle our code with calls to the GC so naturally our
>> heap grows until the JVM starts running out of space and _it_
>> decides to do a GC for us. This is why you see it's partition
>> growing. I suggest you use the monitor to do your checking.
>>
>> I even tried cycling through several JSVGViewerFrames to see if old
>> documents were hanging around and as far as I could tell they
>> weren't.
>>
HS> Has nobody the same experience like me with JSVGCanvas? Is there
HS> a workaround?
>> I certainly haven't heard about it on the list. I still think the
>> problem is dangling references...
>>
HS> Thanks for any help.
>>
HS> Hans
>>
HS> "Thomas E Deweese" <th...@kodak.com> schrieb im
HS> Newsbeitrag news:16020.817.728658.44321@frog.rl.kodak.com...
>> >> >>>>> "HS" == Hans Stoessel <hs...@pm-medici.ch> writes:
>> >>
HS> Hi I use the following source code to display a svg file with a
HS> chart in a dialog:
>> >> You are only showing the init code. Since you create a new >>
>> JSVGCanvas each time, I suspect that you are somehow holding on to
>> >> a reference to the JSVGCanvas (or the dialog) somewhere in your
>> >> code (often this can be hidden in a listener or something).
>> >>
>> >> While I can't rule out memory leaks in Batik (in fact I'd be >>
>> surprised if there weren't at least a few) I don't think there are
>> >> _gross_ memory leaks (I often view >100 SVG files in squiggle
>> w/o a >> problem).
>> >>
HS> If I do that a few times, then I have the java error:
HS> java.lang.OutOfMemoryError <<no stack trace available>>
>> >>
HS> I use Batik 1.5 Beta 5 and Windows 2000. If I have a look in the
HS> task manager of windows, I see that the memory is increasing with
HS> every time I display a SVG file in my dialog.
>> >>
HS> What could be wrong?
>> >>
HS> Thanks for help
>>
HS> ---------------------------------------------------------------------
HS> To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org For
HS> additional commands, e-mail: batik-users-help@xml.apache.org
HS> ---------------------------------------------------------------------
HS> To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org For
HS> additional commands, e-mail: batik-users-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: JSVGCanvas: java.lang.OutOfMemoryError
Posted by Hans Stoessel <hs...@pm-medici.ch>.
I try it with the memory monitor and the memory is increasing with every
using of JSVGCanvas. And I can't reach a solid baseline if I call the
carbage collector manially. I have a look to my code again and I don't think
there is a reference dangling. Could it be, that is a problem with the SVG
file? I can't imaging that, but I really don't know where I can find the
memory leak...
Thanks
Hans
"Thomas E Deweese" <th...@kodak.com> schrieb im Newsbeitrag
news:16020.12887.411199.423737@frog.rl.kodak.com...
> >>>>> "HS" == Hans Stoessel <hs...@pm-medici.ch> writes:
>
> HS> I think its definitely a bug in JSVGCanvas. You can reproduce it
> HS> with the application batik-squiggle who uses JSVGCanvas to display
> HS> SVG files. If you open a SVG file in it and reload this file a few
> HS> times, you see in the task manager of Windows 2000 how the memory
> HS> is increasing...
>
> Squiggle has a built in Memory monitor (with a GC button). When I
> use that with say samples/mapSpain.svg I can load it dozens of times
> and if I press collect two/three times the memory quickly returns to a
> solid baseline. This is even true for 3d.svg (dyanmic document) - it
> actually has a lower baseline since we cache lots of image data for
> static documents.
>
> We do not sprinkle our code with calls to the GC so naturally our
> heap grows until the JVM starts running out of space and _it_ decides
> to do a GC for us. This is why you see it's partition growing. I
> suggest you use the monitor to do your checking.
>
> I even tried cycling through several JSVGViewerFrames to see if
> old documents were hanging around and as far as I could tell they
> weren't.
>
> HS> Has nobody the same experience like me with JSVGCanvas? Is there
> HS> a workaround?
>
> I certainly haven't heard about it on the list. I still think the
> problem is dangling references...
>
> HS> Thanks for any help.
>
> HS> Hans
>
> HS> "Thomas E Deweese" <th...@kodak.com> schrieb im
> HS> Newsbeitrag news:16020.817.728658.44321@frog.rl.kodak.com...
> >> >>>>> "HS" == Hans Stoessel <hs...@pm-medici.ch> writes:
> >>
> HS> Hi I use the following source code to display a svg file with a
> HS> chart in a dialog:
> >> You are only showing the init code. Since you create a new
> >> JSVGCanvas each time, I suspect that you are somehow holding on to
> >> a reference to the JSVGCanvas (or the dialog) somewhere in your
> >> code (often this can be hidden in a listener or something).
> >>
> >> While I can't rule out memory leaks in Batik (in fact I'd be
> >> surprised if there weren't at least a few) I don't think there are
> >> _gross_ memory leaks (I often view >100 SVG files in squiggle w/o a
> >> problem).
> >>
> HS> If I do that a few times, then I have the java error:
> HS> java.lang.OutOfMemoryError <<no stack trace available>>
> >>
> HS> I use Batik 1.5 Beta 5 and Windows 2000. If I have a look in the
> HS> task manager of windows, I see that the memory is increasing with
> HS> every time I display a SVG file in my dialog.
> >>
> HS> What could be wrong?
> >>
> HS> Thanks for help
>
>
>
>
> HS> ---------------------------------------------------------------------
> HS> To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org For
> HS> additional commands, e-mail: batik-users-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: JSVGCanvas: java.lang.OutOfMemoryError
Posted by Thomas E Deweese <th...@kodak.com>.
>>>>> "HS" == Hans Stoessel <hs...@pm-medici.ch> writes:
HS> I think its definitely a bug in JSVGCanvas. You can reproduce it
HS> with the application batik-squiggle who uses JSVGCanvas to display
HS> SVG files. If you open a SVG file in it and reload this file a few
HS> times, you see in the task manager of Windows 2000 how the memory
HS> is increasing...
Squiggle has a built in Memory monitor (with a GC button). When I
use that with say samples/mapSpain.svg I can load it dozens of times
and if I press collect two/three times the memory quickly returns to a
solid baseline. This is even true for 3d.svg (dyanmic document) - it
actually has a lower baseline since we cache lots of image data for
static documents.
We do not sprinkle our code with calls to the GC so naturally our
heap grows until the JVM starts running out of space and _it_ decides
to do a GC for us. This is why you see it's partition growing. I
suggest you use the monitor to do your checking.
I even tried cycling through several JSVGViewerFrames to see if
old documents were hanging around and as far as I could tell they
weren't.
HS> Has nobody the same experience like me with JSVGCanvas? Is there
HS> a workaround?
I certainly haven't heard about it on the list. I still think the
problem is dangling references...
HS> Thanks for any help.
HS> Hans
HS> "Thomas E Deweese" <th...@kodak.com> schrieb im
HS> Newsbeitrag news:16020.817.728658.44321@frog.rl.kodak.com...
>> >>>>> "HS" == Hans Stoessel <hs...@pm-medici.ch> writes:
>>
HS> Hi I use the following source code to display a svg file with a
HS> chart in a dialog:
>> You are only showing the init code. Since you create a new
>> JSVGCanvas each time, I suspect that you are somehow holding on to
>> a reference to the JSVGCanvas (or the dialog) somewhere in your
>> code (often this can be hidden in a listener or something).
>>
>> While I can't rule out memory leaks in Batik (in fact I'd be
>> surprised if there weren't at least a few) I don't think there are
>> _gross_ memory leaks (I often view >100 SVG files in squiggle w/o a
>> problem).
>>
HS> If I do that a few times, then I have the java error:
HS> java.lang.OutOfMemoryError <<no stack trace available>>
>>
HS> I use Batik 1.5 Beta 5 and Windows 2000. If I have a look in the
HS> task manager of windows, I see that the memory is increasing with
HS> every time I display a SVG file in my dialog.
>>
HS> What could be wrong?
>>
HS> Thanks for help
HS> ---------------------------------------------------------------------
HS> To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org For
HS> additional commands, e-mail: batik-users-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: JSVGCanvas: java.lang.OutOfMemoryError
Posted by Hans Stoessel <hs...@pm-medici.ch>.
I think its definitely a bug in JSVGCanvas. You can reproduce it with the
application batik-squiggle who uses JSVGCanvas to display SVG files. If you
open a SVG file in it and reload this file a few times, you see in the task
manager of Windows 2000 how the memory is increasing...
Has nobody the same experience like me with JSVGCanvas?
Is there a workaround?
Thanks for any help.
Hans
"Thomas E Deweese" <th...@kodak.com> schrieb im Newsbeitrag
news:16020.817.728658.44321@frog.rl.kodak.com...
> >>>>> "HS" == Hans Stoessel <hs...@pm-medici.ch> writes:
>
> HS> Hi I use the following source code to display a svg file with a
> HS> chart in a dialog:
>
> You are only showing the init code. Since you create a new
> JSVGCanvas each time, I suspect that you are somehow holding on to a
> reference to the JSVGCanvas (or the dialog) somewhere in your code
> (often this can be hidden in a listener or something).
>
> While I can't rule out memory leaks in Batik (in fact I'd be
> surprised if there weren't at least a few) I don't think there are
> _gross_ memory leaks (I often view >100 SVG files in squiggle w/o a
> problem).
>
> HS> If I do that a few times, then I have the java error:
> HS> java.lang.OutOfMemoryError <<no stack trace available>>
>
> HS> I use Batik 1.5 Beta 5 and Windows 2000. If I have a look in the
> HS> task manager of windows, I see that the memory is increasing with
> HS> every time I display a SVG file in my dialog.
>
> HS> What could be wrong?
>
> HS> Thanks for help
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: JSVGCanvas: java.lang.OutOfMemoryError
Posted by Hans Stoessel <hs...@pm-medici.ch>.
Hi
I don't think, that I hold a reference to JSVGCanvas in my application. I
think, its a problem of JSVGCanvas, but I'm not sure of course. I send you
the whole class, where I use JSVGCanvas, its the only class I use it. After
the class, you will find the only implementation of this class in my
application. Every time I display a SVG file, I create a class DialogChart
and show it. After that, I set the Dialog oDialogChart to null. At least,
you will find a routine for garbage collection. I call this routine several
times in my application, also after I set oDialogChart to null.
This is all I do with JSVGCanvas and I can see that the memory is increased
and increased. I don't know why. Maybe you have an idea.
How do you use JSVGCanvas? Maybe you have a short code example for me.
Thanks for the help.
Hans
//**************************************************************************
**
// Begin class DialogChart and some subclasses
//**************************************************************************
**
package ch.pmm.chartstudio.chartgen;
import ch.pmm.chartstudio.*;
import ch.pmm.chartstudio.chartstudio.ChartStudio;
import ch.pmm.util.StringFormat;
import java.awt.*;
import java.awt.event.*;
import javax.swing.*;
import javax.swing.border.*;
import java.io.File;
// Batik
import org.apache.batik.swing.JSVGCanvas;
import org.apache.batik.swing.svg.SVGDocumentLoaderAdapter;
import org.apache.batik.swing.svg.SVGDocumentLoaderEvent;
import org.apache.batik.dom.svg.SVGDOMImplementation;
import org.apache.batik.dom.svg.SVGDocumentFactory;
import org.apache.batik.dom.svg.SAXSVGDocumentFactory;
import org.apache.batik.swing.svg.GVTTreeBuilderAdapter;
import org.apache.batik.swing.svg.GVTTreeBuilderEvent;
import org.apache.batik.swing.gvt.GVTTreeRendererAdapter;
import org.apache.batik.swing.gvt.GVTTreeRendererEvent;
import org.w3c.dom.svg.SVGDocument;
/**
* <p>Title: </p>
* <p>Description: </p>
* <p>Copyright: Copyright (c) 2002</p>
* <p>Company: PM Medici AG</p>
* @author Oliver Hirschi
* @version 1.0
*/
public class DialogChart extends Dialog1 {
private JPanel m_oJPanelChart;
private PanelDialogChart_Button m_oButton;
private String m_sFilenameChart = null;
private JLabel m_oJLabelState;
private JTextField m_oJTextFieldState;
private SVGDocument m_oSVGDocument = null;
private JSVGCanvas m_oSVGCanvas = null;
//--------------------------------------------------------------------------
// Konstruktor
//--------------------------------------------------------------------------
public DialogChart(Application oApp, String sFilenameChart) {
super(oApp, Constant.LANG_DIALOG_CHARTGENERATE);
m_oDialogSize = new Dimension(Constant.DIALOGDYNTEXT_X,
Constant.DIALOGDYNTEXT_Y);
m_sFilenameChart = sFilenameChart;
m_oLanguage = new Language(Constant.LANG_DIALOG_CHART);
try {
jbInit();
m_bDialogInit = true;
}
catch(Exception ex) {
ex.printStackTrace();
}
}
//--------------------------------------------------------------------------
// Filename zur�ckgeben
//--------------------------------------------------------------------------
public String getFilenameChart() { return m_sFilenameChart; }
public SVGDocument readSVGDocument(String uri) {
SVGDocumentFactory df = new
SAXSVGDocumentFactory("org.apache.crimson.parser.XMLReaderImpl");
try {
return df.createSVGDocument(uri);
}
catch (java.io.IOException ioe) {
ioe.printStackTrace();
}
return null;
}
//--------------------------------------------------------------------------
// Dialog initialisieren
//--------------------------------------------------------------------------
private void jbInit() throws Exception {
ChartStudio oApp = (ChartStudio) getApp();
// Rand
Border oBorderLabel = new EmptyBorder(0, 0, 0, 10);
// Panel
m_oJPanelChart = new JPanel(new GridBagLayout());
m_oJPanelChart.setBorder(new TitledBorder(new EtchedBorder()));
// Constraints
GridBagConstraints c = new GridBagConstraints();
c.insets = new Insets(2, 2, 2, 2);
c.anchor = GridBagConstraints.WEST;
// SVG-File
m_oSVGCanvas = new JSVGCanvas();
// Set the JSVGCanvas listeners.
m_oSVGCanvas.addSVGDocumentLoaderListener(new
DialogChartSVGDocumentLoaderAdapter(this));
m_oSVGCanvas.addGVTTreeBuilderListener(new
DialogChartGVTTreeBuilderAdapter(this));
m_oSVGCanvas.addGVTTreeRendererListener(new
DialogChartGVTTreeRendererAdapter(this));
//m_oSVGCanvas.setURI(new File(m_sFilenameChart).toURL().toString());
m_oSVGDocument = readSVGDocument(new
File(m_sFilenameChart).toURL().toString());
m_oSVGCanvas.setSVGDocument(m_oSVGDocument);
c.gridx = 1;
c.gridy = 0;
c.gridwidth = 2;
m_oJPanelChart.add(m_oSVGCanvas, c);
// Label Schriftstil
c.gridx = 0;
c.gridy++;
c.gridwidth = 1;
m_oJLabelState = new JLabel(m_oLanguage.getText(1051) + ":");
m_oJLabelState.setBorder(oBorderLabel);
m_oJPanelChart.add(m_oJLabelState, c);
// Textfeld Schriftstil
c.gridx++;
m_oJTextFieldState = new JTextField(Constant.DIALOG_COLUMN_LEN30);
m_oJTextFieldState.setEnabled(false);
m_oJPanelChart.add(m_oJTextFieldState, c);
// Buttons
m_oButton = new PanelDialogChart_Button();
// Dialog bauen
JPanel oJPanel = new JPanel(new BorderLayout());
oJPanel.setBorder(new EmptyBorder(10, 10, 10, 10));
oJPanel.add(m_oJPanelChart, BorderLayout.CENTER);
oJPanel.add(m_oButton, BorderLayout.SOUTH);
setTitle(m_oLanguage.getText(1050));
getContentPane().add(oJPanel);
setResizable(false);
centerWindow();
}
//--------------------------------------------------------------------------
// Statustext setzen
//--------------------------------------------------------------------------
public void setStateText(int iText) {
m_oJTextFieldState.setText(m_oLanguage.getText(iText));
}
//--------------------------------------------------------------------------
// SVG-Datei eingelesen -> Aufbau des Dialog beendet
//--------------------------------------------------------------------------
public void finishDialog() {
m_oJPanelChart.remove(m_oJLabelState);
m_oJPanelChart.remove(m_oJTextFieldState);
pack();
centerWindow();
}
}
//--------------------------------------------------------------------------
--
// Panel mit Buttons
//--------------------------------------------------------------------------
--
class PanelDialogChart_Button extends Panel2 {
//--------------------------------------------------------------------------
// Konstruktor
//--------------------------------------------------------------------------
public PanelDialogChart_Button() {
super();
m_oJButtonOK.setVisible(false);
m_oJButtonCancel.setText(Language.END);
}
//--------------------------------------------------------------------------
// Action behandeln
//--------------------------------------------------------------------------
public void actionPerformed(ActionEvent e) {
DialogChart oDialog = (DialogChart) getDialog();
if (e.getSource() == m_oJButtonCancel) {
File oFile = new File(oDialog.getFilenameChart());
if (oFile.exists()) oFile.delete();
oDialog.setAction(Constant.ACTION_CANCEL);
oDialog.setVisible(false);
}
}
}
//--------------------------------------------------------------------------
--
// GVTTreeRendererAdapter
//--------------------------------------------------------------------------
--
class DialogChartGVTTreeRendererAdapter extends GVTTreeRendererAdapter {
DialogChart m_oDialogChart = null;
//--------------------------------------------------------------------------
// Konstruktor
//--------------------------------------------------------------------------
public DialogChartGVTTreeRendererAdapter(DialogChart oDialogChart) {
super();
m_oDialogChart = oDialogChart;
}
//--------------------------------------------------------------------------
// Rendering starten
//--------------------------------------------------------------------------
public void gvtRenderingPrepare(GVTTreeRendererEvent e) {
m_oDialogChart.setStateText(1056);
}
//--------------------------------------------------------------------------
// Rendering beenden
//--------------------------------------------------------------------------
public void gvtRenderingCompleted(GVTTreeRendererEvent e) {
m_oDialogChart.setStateText(1057);
m_oDialogChart.finishDialog();
}
}
//--------------------------------------------------------------------------
--
// SVGDocumentLoaderAdapter
//--------------------------------------------------------------------------
--
class DialogChartSVGDocumentLoaderAdapter extends SVGDocumentLoaderAdapter {
DialogChart m_oDialogChart = null;
//--------------------------------------------------------------------------
// Konstruktor
//--------------------------------------------------------------------------
public DialogChartSVGDocumentLoaderAdapter(DialogChart oDialogChart) {
super();
m_oDialogChart = oDialogChart;
}
//--------------------------------------------------------------------------
// Dokument laden beginnt
//--------------------------------------------------------------------------
public void documentLoadingStarted(SVGDocumentLoaderEvent e) {
m_oDialogChart.setStateText(1052);
}
//--------------------------------------------------------------------------
// Dokument laden beendet
//--------------------------------------------------------------------------
public void documentLoadingCompleted(SVGDocumentLoaderEvent e) {
m_oDialogChart.setStateText(1053);
}
}
//--------------------------------------------------------------------------
--
// GVTTreeBuilderAdapter
//--------------------------------------------------------------------------
--
class DialogChartGVTTreeBuilderAdapter extends GVTTreeBuilderAdapter {
DialogChart m_oDialogChart = null;
//--------------------------------------------------------------------------
// Konstruktor
//--------------------------------------------------------------------------
public DialogChartGVTTreeBuilderAdapter(DialogChart oDialogChart) {
super();
m_oDialogChart = oDialogChart;
}
//--------------------------------------------------------------------------
// Baum wird aufgebaut
//--------------------------------------------------------------------------
public void gvtBuildStarted(GVTTreeBuilderEvent e) {
m_oDialogChart.setStateText(1054);
}
//--------------------------------------------------------------------------
// Baum fertig
//--------------------------------------------------------------------------
public void gvtBuildCompleted(GVTTreeBuilderEvent e) {
m_oDialogChart.setStateText(1055);
}
}
//**************************************************************************
**
// End class DialogChart and some subclasses
//**************************************************************************
**
//**************************************************************************
**
// Begin Implementation
//**************************************************************************
**
DialogChart oDialogChart = new DialogChart(oDialog.getApp(),
oDialogChartGenerate.getProdJob().getSVGPath(true));
oDialogChart.show();
oDialogChart = null;
Application.gc();
//**************************************************************************
**
// End Implementation
//**************************************************************************
**
//**************************************************************************
**
// Begin Application.gc
//**************************************************************************
**
//--------------------------------------------------------------------------
// Garbage Coolection
//--------------------------------------------------------------------------
public static void gc() {
Runtime rt = Runtime.getRuntime();
long isFree = rt.freeMemory();
long wasFree = 0;
do {
wasFree = isFree;
rt.runFinalization();
rt.gc();
isFree = rt.freeMemory();
} while (isFree > wasFree);
}
//**************************************************************************
**
// End Application.gc
//**************************************************************************
**
"Thomas E Deweese" <th...@kodak.com> schrieb im Newsbeitrag
news:16020.817.728658.44321@frog.rl.kodak.com...
> >>>>> "HS" == Hans Stoessel <hs...@pm-medici.ch> writes:
>
> HS> Hi I use the following source code to display a svg file with a
> HS> chart in a dialog:
>
> You are only showing the init code. Since you create a new
> JSVGCanvas each time, I suspect that you are somehow holding on to a
> reference to the JSVGCanvas (or the dialog) somewhere in your code
> (often this can be hidden in a listener or something).
>
> While I can't rule out memory leaks in Batik (in fact I'd be
> surprised if there weren't at least a few) I don't think there are
> _gross_ memory leaks (I often view >100 SVG files in squiggle w/o a
> problem).
>
> HS> If I do that a few times, then I have the java error:
> HS> java.lang.OutOfMemoryError <<no stack trace available>>
>
> HS> I use Batik 1.5 Beta 5 and Windows 2000. If I have a look in the
> HS> task manager of windows, I see that the memory is increasing with
> HS> every time I display a SVG file in my dialog.
>
> HS> What could be wrong?
>
> HS> Thanks for help
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
RE: JSVGCanvas: java.lang.OutOfMemoryError
Posted by Thomas E Deweese <th...@kodak.com>.
>>>>> "HS" == Hans Stoessel <hs...@pm-medici.ch> writes:
HS> Hi I use the following source code to display a svg file with a
HS> chart in a dialog:
You are only showing the init code. Since you create a new
JSVGCanvas each time, I suspect that you are somehow holding on to a
reference to the JSVGCanvas (or the dialog) somewhere in your code
(often this can be hidden in a listener or something).
While I can't rule out memory leaks in Batik (in fact I'd be
surprised if there weren't at least a few) I don't think there are
_gross_ memory leaks (I often view >100 SVG files in squiggle w/o a
problem).
HS> If I do that a few times, then I have the java error:
HS> java.lang.OutOfMemoryError <<no stack trace available>>
HS> I use Batik 1.5 Beta 5 and Windows 2000. If I have a look in the
HS> task manager of windows, I see that the memory is increasing with
HS> every time I display a SVG file in my dialog.
HS> What could be wrong?
HS> Thanks for help
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: JSVGCanvas: java.lang.OutOfMemoryError
Posted by Thomas E Deweese <th...@kodak.com>.
>>>>> "SB" == Sergey Beryozkin <sb...@zandar.com> writes:
>> 3) The reason your changes slow the leak down is because you are
>> essentially striping the DOM down to nothing but what is left is
>> still being referenced...
SB> It would be useful to be able to explicitly set the DOM to null by
SB> setSVGDocument(null). It may help not only with preventing the
SB> leaks, but also be useful in some application scenarious (no svg
SB> doc is currently selected, for ex). At the moment this method
SB> call throws NullPointerException.
This has worked and then stopped working a couple times in the
past. It is fairly tricky to keep it working. It is I agree useful
behavior.
However, I disagree that this would help with preventing leaks,
after all loading a new document also requires clearing all references
to the old document or else there is a memory leak. It might help
hide application based memory leaks where the application is holding
onto the JSVGCanvas (as once it was set to a null document it wouldn't
have any large resources associated). But in general if the leak is
there for loading new documents it will be there for setting the
document to null.
This all said I would encourage the filing of a bug report, or
even better the development of a patch.
SB> Thanks Sergey Beryozkin
SB> ----- Original Message ----- From: "Thomas E Deweese"
SB> <th...@kodak.com> To: "Batik Users"
SB> <ba...@xml.apache.org> Sent: Wednesday, April 23, 2003 7:27
SB> PM Subject: Re: JSVGCanvas: java.lang.OutOfMemoryError
>> Hi Hans,
>>
>> Warning this is a general Brain Dump (I don't have lots of time to
>> poke at this).
>>
>> 1) I suspect the NPE is being caused by the clip-path elements
>> (This is I think a bug in general for Batik - unfortunately I think
>> a will be a very tricky bug to fix). I don't think this is the
>> direct cause of your problems (although it may be making it worse).
>>
>> 2) I think something somewhere is telling the the BridgeContext to
>> be dynamic! Otherwise the listener that is failing for shape nodes
>> would never get registered at all.
>>
>> 3) The reason your changes slow the leak down is because you are
>> essentially striping the DOM down to nothing but what is left is
>> still being referenced...
>>
>> 4) I was wondering if you reused your Dialog objects at all?
>>
>> 5) I couldn't get Squiggle to run out of memory by creating new
>> viewer frames and loading your document into them (although it did
>> use a _lot_ of memory - I suspect due to the clip-path stuff - see
>> below).
>>
>> 6) Some content suggestions - your document contained some 3200
>> clip-path usages of just 15 clip paths! I think you will find your
>> documents load and display much faster if you group objects that
>> are using the same clip path and then put the clip-path
>> specification on the group.
>>
>> Also you seem to be using lots of line elements to build the graph.
>> I would strongly suggest that you build one path element using lots
>> of 'L' commands:
>>
>> <line x1="27.093748588225147" x2="27.25791729263496"
SB> y1="107.57115742927745" style="clip-path:url(#clipPath15);
SB> fill:none;" y2="107.57115742927745" />
>> <line x1="27.25791729263496" x2="27.422085997044775"
SB> y1="107.57115742927745" style="clip-path:url(#clipPath15);
SB> fill:none;" y2="107.29939936269608" />
>> <line x1="27.422085997044775" x2="27.58625470145459"
SB> y1="107.29939936269608" style="clip-path:url(#clipPath15);
SB> fill:none;" y2="107.21308615407727" />
>> becomes:
>>
>> <path style="clip-path:url(#clipPath15); fill:none;"
>> d="M27.093748588225147 107.57115742927745 L27.25791729263496
>> 107.57115742927745 L27.422085997044775 107.29939936269608
>> L27.58625470145459 107.21308615407727"/>
>>
>> As a side effect your stroke-dash-array specification will then
>> actually do something.
>>
>> >>>>> "HS" == Hans Stoessel <hs...@pm-medici.ch> writes:
>>
HS> Hi If I flush the SVG document with the following methods it
HS> works. But the memory is still increasing, but slower than before:
>>
HS>
SB> //--------------------------------------------------------------------------
HS> // Flush SVG document
>> uit
HS>
SB> //--------------------------------------------------------------------------
HS> public void flushSVGDocument() { Node childNode = null;
HS> SVGDocument oSVGDocument = m_oSVGCanvas.getSVGDocument();
>>
HS> if (oSVGDocument != null) { SVGSVGElement s =
HS> oSVGDocument.getRootElement(); removeNodes(s); } System.gc(); }
>>
HS>
SB> //--------------------------------------------------------------------------
HS> // Flush node
HS>
SB> //--------------------------------------------------------------------------
HS> private void removeNodes(Node n) { Node childNode = null; Node
HS> prevChildNode = null;
>>
HS> for (childNode = n.getLastChild(); childNode != null;) { if
HS> (childNode.hasChildNodes()) { removeNodes(childNode); }
HS> prevChildNode = childNode.getPreviousSibling(); if (!(childNode
HS> instanceof SVGOMPathElement)) { n.removeChild(childNode); }
HS> childNode = null; childNode = prevChildNode; } n = null; }
>>
HS> If I try to remove a node which is an instance of SVGOMPathElement
HS> I have an exception (Null pointer).
>>
HS> Maybe that helps a bit to solve the problem
>>
HS> Hans
>>
HS> ---------------------------------------------------------------------
HS> To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org For
HS> additional commands, e-mail: batik-users-help@xml.apache.org
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org For
>> additional commands, e-mail: batik-users-help@xml.apache.org
>>
>>
>>
SB> ---------------------------------------------------------------------
SB> To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org For
SB> additional commands, e-mail: batik-users-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: JSVGCanvas: java.lang.OutOfMemoryError
Posted by Sergey Beryozkin <sb...@zandar.com>.
Hello,
> 3) The reason your changes slow the leak down is because you are
> essentially striping the DOM down to nothing but what is left
> is still being referenced...
It would be useful to be able to explicitly set the DOM to null by
setSVGDocument(null). It may help not only with preventing the leaks, but
also be useful in some application scenarious (no svg doc is currently
selected, for ex).
At the moment this method call throws NullPointerException.
Thanks
Sergey Beryozkin
----- Original Message -----
From: "Thomas E Deweese" <th...@kodak.com>
To: "Batik Users" <ba...@xml.apache.org>
Sent: Wednesday, April 23, 2003 7:27 PM
Subject: Re: JSVGCanvas: java.lang.OutOfMemoryError
>
> Hi Hans,
>
> Warning this is a general Brain Dump (I don't have lots of time
> to poke at this).
>
> 1) I suspect the NPE is being caused by the clip-path elements
> (This is I think a bug in general for Batik - unfortunately I
> think a will be a very tricky bug to fix). I don't think this
> is the direct cause of your problems (although it may be making
> it worse).
>
> 2) I think something somewhere is telling the the BridgeContext to
> be dynamic! Otherwise the listener that is failing for shape
> nodes would never get registered at all.
>
> 3) The reason your changes slow the leak down is because you are
> essentially striping the DOM down to nothing but what is left
> is still being referenced...
>
> 4) I was wondering if you reused your Dialog objects at all?
>
> 5) I couldn't get Squiggle to run out of memory by creating new
> viewer frames and loading your document into them (although it
> did use a _lot_ of memory - I suspect due to the clip-path stuff
> - see below).
>
> 6) Some content suggestions - your document contained some 3200
> clip-path usages of just 15 clip paths! I think you will find
> your documents load and display much faster if you group objects
> that are using the same clip path and then put the clip-path
> specification on the group.
>
> Also you seem to be using lots of line elements to build the
> graph. I would strongly suggest that you build one path element
> using lots of 'L' commands:
>
> <line x1="27.093748588225147" x2="27.25791729263496"
y1="107.57115742927745" style="clip-path:url(#clipPath15); fill:none;"
y2="107.57115742927745" />
> <line x1="27.25791729263496" x2="27.422085997044775"
y1="107.57115742927745" style="clip-path:url(#clipPath15); fill:none;"
y2="107.29939936269608" />
> <line x1="27.422085997044775" x2="27.58625470145459"
y1="107.29939936269608" style="clip-path:url(#clipPath15); fill:none;"
y2="107.21308615407727" />
>
> becomes:
>
> <path style="clip-path:url(#clipPath15); fill:none;"
> d="M27.093748588225147 107.57115742927745
> L27.25791729263496 107.57115742927745
> L27.422085997044775 107.29939936269608
> L27.58625470145459 107.21308615407727"/>
>
> As a side effect your stroke-dash-array specification will then
> actually do something.
>
> >>>>> "HS" == Hans Stoessel <hs...@pm-medici.ch> writes:
>
> HS> Hi If I flush the SVG document with the following methods it
> HS> works. But the memory is still increasing, but slower than before:
>
> HS>
//--------------------------------------------------------------------------
> HS> // Flush SVG document
> uit
> HS>
//--------------------------------------------------------------------------
> HS> public void flushSVGDocument() { Node childNode = null;
> HS> SVGDocument oSVGDocument = m_oSVGCanvas.getSVGDocument();
>
> HS> if (oSVGDocument != null) { SVGSVGElement s =
> HS> oSVGDocument.getRootElement(); removeNodes(s); } System.gc(); }
>
> HS>
//--------------------------------------------------------------------------
> HS> // Flush node
> HS>
//--------------------------------------------------------------------------
> HS> private void removeNodes(Node n) { Node childNode = null; Node
> HS> prevChildNode = null;
>
> HS> for (childNode = n.getLastChild(); childNode != null;) { if
> HS> (childNode.hasChildNodes()) { removeNodes(childNode); }
> HS> prevChildNode = childNode.getPreviousSibling(); if (!(childNode
> HS> instanceof SVGOMPathElement)) { n.removeChild(childNode); }
> HS> childNode = null; childNode = prevChildNode; } n = null; }
>
> HS> If I try to remove a node which is an instance of SVGOMPathElement
> HS> I have an exception (Null pointer).
>
> HS> Maybe that helps a bit to solve the problem
>
> HS> Hans
>
>
>
>
> HS> ---------------------------------------------------------------------
> HS> To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org For
> HS> additional commands, e-mail: batik-users-help@xml.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: batik-users-help@xml.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: JSVGCanvas: java.lang.OutOfMemoryError
Posted by Thomas E Deweese <th...@kodak.com>.
>>>>> "HS" == Hans Stoessel <hs...@pm-medici.ch> writes:
HS> What is the BridgeContext?
The bridge context manages the construction of the rendering tree.
It is normally buried in the JSVGCanvas or the GVTBuilder.
HS> What do you mean with "the BridgeContext to be dynamic"?
For static content the rendering tree should be 100% independent
of the SVGDOM. For dynamic content however they are linked by event
listeners.
There are three states the JSVGCanvas can be in, always static,
always dynamic, and check the content. Yoour visiblity to this is
throught the JSVGCanvas.setDocumentState and you are properly calling
it with ALWAYS_STATIC - yet somewhere it must be deciding it is
dynamic otherwise the DOMNodeRemoved listener would not be called.
HS> What or where could tell that the BridgeContext is dynamic?
It's pretty easy to get your hands on the BridgeContext then there
is just a method 'bridge.Bridgecontext.setDynamic(boolean);' There
is also the method swing.svg.JSVGCanvas.setDocumentState(...).
Aha, just following through the file I noticed what seems to be a
BUG! Thierry, Stephane, Vincent any ideas, is the
'result.setDynamic(true)' intentional? I think it should be
'result.setDynamic(isDynamicDocument)'. Is there some reason this is
not done?
/**
* Creates a new bridge context.
*/
protected BridgeContext createBridgeContext() {
if (loader == null) {
loader = new DocumentLoader(userAgent);
}
BridgeContext result = new BridgeContext(userAgent, loader);
result.setDynamic(true);
return result;
}
HS> What I have to looking for?
Well the above seems to be a big part of it.
HS> How can I change that?
You could try my suggested fix, I am nervous that for some reason
they wanted the listeners registered (for text selction or
something?).
HS> Maybe you can give me a tip.
BTW, while I think it is important to figure out this memory
leak/bug, you should still change your content to use the path (or
polyline/polygon elements.
HS> Thanks for your help
HS> Hans
HS> "Thomas E Deweese" <th...@kodak.com> schrieb im
HS> Newsbeitrag news:16038.56100.283478.792899@frog.rl.kodak.com...
>> Hi Hans,
>>
>> Warning this is a general Brain Dump (I don't have lots of time to
>> poke at this).
>>
>> 1) I suspect the NPE is being caused by the clip-path elements
>> (This is I think a bug in general for Batik - unfortunately I think
>> a will be a very tricky bug to fix). I don't think this is the
>> direct cause of your problems (although it may be making it worse).
>>
>> 2) I think something somewhere is telling the the BridgeContext to
>> be dynamic! Otherwise the listener that is failing for shape nodes
>> would never get registered at all.
>>
>> 3) The reason your changes slow the leak down is because you are
>> essentially striping the DOM down to nothing but what is left is
>> still being referenced...
>>
>> 4) I was wondering if you reused your Dialog objects at all?
>>
>> 5) I couldn't get Squiggle to run out of memory by creating new
>> viewer frames and loading your document into them (although it did
>> use a _lot_ of memory - I suspect due to the clip-path stuff - see
>> below).
>>
>> 6) Some content suggestions - your document contained some 3200
>> clip-path usages of just 15 clip paths! I think you will find your
>> documents load and display much faster if you group objects that
>> are using the same clip path and then put the clip-path
>> specification on the group.
>>
>> Also you seem to be using lots of line elements to build the graph.
>> I would strongly suggest that you build one path element using lots
>> of 'L' commands:
>>
>> <line x1="27.093748588225147" x2="27.25791729263496"
HS> y1="107.57115742927745" style="clip-path:url(#clipPath15);
HS> fill:none;" y2="107.57115742927745" />
>> <line x1="27.25791729263496" x2="27.422085997044775"
HS> y1="107.57115742927745" style="clip-path:url(#clipPath15);
HS> fill:none;" y2="107.29939936269608" />
>> <line x1="27.422085997044775" x2="27.58625470145459"
HS> y1="107.29939936269608" style="clip-path:url(#clipPath15);
HS> fill:none;" y2="107.21308615407727" />
>> becomes:
>>
>> <path style="clip-path:url(#clipPath15); fill:none;"
>> d="M27.093748588225147 107.57115742927745 L27.25791729263496
>> 107.57115742927745 L27.422085997044775 107.29939936269608
>> L27.58625470145459 107.21308615407727"/>
>>
>> As a side effect your stroke-dash-array specification will then
>> actually do something.
>>
>> >>>>> "HS" == Hans Stoessel <hs...@pm-medici.ch> writes:
>>
HS> Hi If I flush the SVG document with the following methods it
HS> works. But the memory is still increasing, but slower than before:
>>
HS>
HS> //--------------------------------------------------------------------------
HS> // Flush SVG document
>> uit
HS>
HS> //--------------------------------------------------------------------------
HS> public void flushSVGDocument() { Node childNode = null;
HS> SVGDocument oSVGDocument = m_oSVGCanvas.getSVGDocument();
>>
HS> if (oSVGDocument != null) { SVGSVGElement s =
HS> oSVGDocument.getRootElement(); removeNodes(s); } System.gc(); }
>>
HS>
HS> //--------------------------------------------------------------------------
HS> // Flush node
HS>
HS> //--------------------------------------------------------------------------
HS> private void removeNodes(Node n) { Node childNode = null; Node
HS> prevChildNode = null;
>>
HS> for (childNode = n.getLastChild(); childNode != null;) { if
HS> (childNode.hasChildNodes()) { removeNodes(childNode); }
HS> prevChildNode = childNode.getPreviousSibling(); if (!(childNode
HS> instanceof SVGOMPathElement)) { n.removeChild(childNode); }
HS> childNode = null; childNode = prevChildNode; } n = null; }
>>
HS> If I try to remove a node which is an instance of SVGOMPathElement
HS> I have an exception (Null pointer).
>>
HS> Maybe that helps a bit to solve the problem
>>
HS> Hans
>>
HS> ---------------------------------------------------------------------
HS> To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org For
HS> additional commands, e-mail: batik-users-help@xml.apache.org
HS> ---------------------------------------------------------------------
HS> To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org For
HS> additional commands, e-mail: batik-users-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: JSVGCanvas: java.lang.OutOfMemoryError
Posted by Hans Stoessel <hs...@pm-medici.ch>.
Hi
What do you mean with "the BridgeContext to be dynamic"?
What is the BridgeContext?
What or where could tell that the BridgeContext is dynamic?
What I have to looking for?
How can I change that?
Maybe you can give me a tip.
Thanks for your help
Hans
"Thomas E Deweese" <th...@kodak.com> schrieb im Newsbeitrag
news:16038.56100.283478.792899@frog.rl.kodak.com...
>
> Hi Hans,
>
> Warning this is a general Brain Dump (I don't have lots of time
> to poke at this).
>
> 1) I suspect the NPE is being caused by the clip-path elements
> (This is I think a bug in general for Batik - unfortunately I
> think a will be a very tricky bug to fix). I don't think this
> is the direct cause of your problems (although it may be making
> it worse).
>
> 2) I think something somewhere is telling the the BridgeContext to
> be dynamic! Otherwise the listener that is failing for shape
> nodes would never get registered at all.
>
> 3) The reason your changes slow the leak down is because you are
> essentially striping the DOM down to nothing but what is left
> is still being referenced...
>
> 4) I was wondering if you reused your Dialog objects at all?
>
> 5) I couldn't get Squiggle to run out of memory by creating new
> viewer frames and loading your document into them (although it
> did use a _lot_ of memory - I suspect due to the clip-path stuff
> - see below).
>
> 6) Some content suggestions - your document contained some 3200
> clip-path usages of just 15 clip paths! I think you will find
> your documents load and display much faster if you group objects
> that are using the same clip path and then put the clip-path
> specification on the group.
>
> Also you seem to be using lots of line elements to build the
> graph. I would strongly suggest that you build one path element
> using lots of 'L' commands:
>
> <line x1="27.093748588225147" x2="27.25791729263496"
y1="107.57115742927745" style="clip-path:url(#clipPath15); fill:none;"
y2="107.57115742927745" />
> <line x1="27.25791729263496" x2="27.422085997044775"
y1="107.57115742927745" style="clip-path:url(#clipPath15); fill:none;"
y2="107.29939936269608" />
> <line x1="27.422085997044775" x2="27.58625470145459"
y1="107.29939936269608" style="clip-path:url(#clipPath15); fill:none;"
y2="107.21308615407727" />
>
> becomes:
>
> <path style="clip-path:url(#clipPath15); fill:none;"
> d="M27.093748588225147 107.57115742927745
> L27.25791729263496 107.57115742927745
> L27.422085997044775 107.29939936269608
> L27.58625470145459 107.21308615407727"/>
>
> As a side effect your stroke-dash-array specification will then
> actually do something.
>
> >>>>> "HS" == Hans Stoessel <hs...@pm-medici.ch> writes:
>
> HS> Hi If I flush the SVG document with the following methods it
> HS> works. But the memory is still increasing, but slower than before:
>
> HS>
//--------------------------------------------------------------------------
> HS> // Flush SVG document
> uit
> HS>
//--------------------------------------------------------------------------
> HS> public void flushSVGDocument() { Node childNode = null;
> HS> SVGDocument oSVGDocument = m_oSVGCanvas.getSVGDocument();
>
> HS> if (oSVGDocument != null) { SVGSVGElement s =
> HS> oSVGDocument.getRootElement(); removeNodes(s); } System.gc(); }
>
> HS>
//--------------------------------------------------------------------------
> HS> // Flush node
> HS>
//--------------------------------------------------------------------------
> HS> private void removeNodes(Node n) { Node childNode = null; Node
> HS> prevChildNode = null;
>
> HS> for (childNode = n.getLastChild(); childNode != null;) { if
> HS> (childNode.hasChildNodes()) { removeNodes(childNode); }
> HS> prevChildNode = childNode.getPreviousSibling(); if (!(childNode
> HS> instanceof SVGOMPathElement)) { n.removeChild(childNode); }
> HS> childNode = null; childNode = prevChildNode; } n = null; }
>
> HS> If I try to remove a node which is an instance of SVGOMPathElement
> HS> I have an exception (Null pointer).
>
> HS> Maybe that helps a bit to solve the problem
>
> HS> Hans
>
>
>
>
> HS> ---------------------------------------------------------------------
> HS> To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org For
> HS> additional commands, e-mail: batik-users-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: JSVGCanvas: java.lang.OutOfMemoryError
Posted by Thomas E Deweese <th...@kodak.com>.
Hi Hans,
Warning this is a general Brain Dump (I don't have lots of time
to poke at this).
1) I suspect the NPE is being caused by the clip-path elements
(This is I think a bug in general for Batik - unfortunately I
think a will be a very tricky bug to fix). I don't think this
is the direct cause of your problems (although it may be making
it worse).
2) I think something somewhere is telling the the BridgeContext to
be dynamic! Otherwise the listener that is failing for shape
nodes would never get registered at all.
3) The reason your changes slow the leak down is because you are
essentially striping the DOM down to nothing but what is left
is still being referenced...
4) I was wondering if you reused your Dialog objects at all?
5) I couldn't get Squiggle to run out of memory by creating new
viewer frames and loading your document into them (although it
did use a _lot_ of memory - I suspect due to the clip-path stuff
- see below).
6) Some content suggestions - your document contained some 3200
clip-path usages of just 15 clip paths! I think you will find
your documents load and display much faster if you group objects
that are using the same clip path and then put the clip-path
specification on the group.
Also you seem to be using lots of line elements to build the
graph. I would strongly suggest that you build one path element
using lots of 'L' commands:
<line x1="27.093748588225147" x2="27.25791729263496" y1="107.57115742927745" style="clip-path:url(#clipPath15); fill:none;" y2="107.57115742927745" />
<line x1="27.25791729263496" x2="27.422085997044775" y1="107.57115742927745" style="clip-path:url(#clipPath15); fill:none;" y2="107.29939936269608" />
<line x1="27.422085997044775" x2="27.58625470145459" y1="107.29939936269608" style="clip-path:url(#clipPath15); fill:none;" y2="107.21308615407727" />
becomes:
<path style="clip-path:url(#clipPath15); fill:none;"
d="M27.093748588225147 107.57115742927745
L27.25791729263496 107.57115742927745
L27.422085997044775 107.29939936269608
L27.58625470145459 107.21308615407727"/>
As a side effect your stroke-dash-array specification will then
actually do something.
>>>>> "HS" == Hans Stoessel <hs...@pm-medici.ch> writes:
HS> Hi If I flush the SVG document with the following methods it
HS> works. But the memory is still increasing, but slower than before:
HS> //--------------------------------------------------------------------------
HS> // Flush SVG document
uit
HS> //--------------------------------------------------------------------------
HS> public void flushSVGDocument() { Node childNode = null;
HS> SVGDocument oSVGDocument = m_oSVGCanvas.getSVGDocument();
HS> if (oSVGDocument != null) { SVGSVGElement s =
HS> oSVGDocument.getRootElement(); removeNodes(s); } System.gc(); }
HS> //--------------------------------------------------------------------------
HS> // Flush node
HS> //--------------------------------------------------------------------------
HS> private void removeNodes(Node n) { Node childNode = null; Node
HS> prevChildNode = null;
HS> for (childNode = n.getLastChild(); childNode != null;) { if
HS> (childNode.hasChildNodes()) { removeNodes(childNode); }
HS> prevChildNode = childNode.getPreviousSibling(); if (!(childNode
HS> instanceof SVGOMPathElement)) { n.removeChild(childNode); }
HS> childNode = null; childNode = prevChildNode; } n = null; }
HS> If I try to remove a node which is an instance of SVGOMPathElement
HS> I have an exception (Null pointer).
HS> Maybe that helps a bit to solve the problem
HS> Hans
HS> ---------------------------------------------------------------------
HS> To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org For
HS> additional commands, e-mail: batik-users-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: JSVGCanvas: java.lang.OutOfMemoryError
Posted by Hans Stoessel <hs...@pm-medici.ch>.
Hi
If I flush the SVG document with the following methods it works. But the
memory is still increasing, but slower than before:
//--------------------------------------------------------------------------
// Flush SVG document
//--------------------------------------------------------------------------
public void flushSVGDocument() {
Node childNode = null;
SVGDocument oSVGDocument = m_oSVGCanvas.getSVGDocument();
if (oSVGDocument != null) {
SVGSVGElement s = oSVGDocument.getRootElement();
removeNodes(s);
}
System.gc();
}
//--------------------------------------------------------------------------
// Flush node
//--------------------------------------------------------------------------
private void removeNodes(Node n) {
Node childNode = null;
Node prevChildNode = null;
for (childNode = n.getLastChild(); childNode != null;) {
if (childNode.hasChildNodes()) {
removeNodes(childNode);
}
prevChildNode = childNode.getPreviousSibling();
if (!(childNode instanceof SVGOMPathElement)) {
n.removeChild(childNode);
}
childNode = null;
childNode = prevChildNode;
}
n = null;
}
If I try to remove a node which is an instance of SVGOMPathElement I have an
exception (Null pointer).
Maybe that helps a bit to solve the problem
Hans
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: JSVGCanvas: java.lang.OutOfMemoryError
Posted by Hans Stoessel <hs...@pm-medici.ch>.
Hi
In my application, the following methods loads and display the SVG file:
//--------------------------------------------------------------------------
// Build dialog (DialogChart) for displaying SVG file
//--------------------------------------------------------------------------
private void jbInit() throws Exception {
...
// Create JSVGCanvas
m_oSVGCanvas = new JSVGCanvas();
m_oSVGCanvas.setDocumentState(JSVGCanvas.ALWAYS_STATIC);
// Set the JSVGCanvas listeners.
m_oSVGCanvas.addSVGDocumentLoaderListener(new
DialogChartSVGDocumentLoaderAdapter(this));
m_oSVGCanvas.addGVTTreeBuilderListener(new
DialogChartGVTTreeBuilderAdapter(this));
m_oSVGCanvas.addGVTTreeRendererListener(new
DialogChartGVTTreeRendererAdapter(this));
// Load SVG document
m_oSVGDocument = loadSVGDocument(new
File(m_sFilenameChart).toURL().toString());
m_oSVGCanvas.setSVGDocument(m_oSVGDocument);
...
}
//--------------------------------------------------------------------------
// Load SVG file
//--------------------------------------------------------------------------
public SVGDocument readSVGDocument(String uri) {
SVGDocumentFactory df = new
SAXSVGDocumentFactory("org.apache.crimson.parser.XMLReaderImpl");
try {
return df.createSVGDocument(uri);
}
catch (java.io.IOException ioe) {
ioe.printStackTrace();
}
return null;
}
m_oSVGCanvas and m_oSVGDocument are member variables from the dialog class:
private JSVGCanvas m_oSVGCanvas = null;
private SVGDocument m_oSVGDocument = null;
If I do that on this way, the memory is increasing with every display of a
SVG file. During my tests, I load the SVG document using the above method,
but don't display it. I mean, I don't use m_oSVGCanvas. After colosing the
dialog (without displaying the SVG file), I flush the memory with the
following methods:
//--------------------------------------------------------------------------
// Flush SVG document
//--------------------------------------------------------------------------
public void flushSVGDocument() {
Node childNode = null;
if (m_oSVGDocument != null) {
SVGSVGElement s = m_oSVGDocument.getRootElement();
removeNodes(s);
}
m_oSVGDocument = null;
System.gc();
}
//--------------------------------------------------------------------------
// Flush Node
//--------------------------------------------------------------------------
private void removeNodes(Node n) {
Node childNode = null;
while (n.hasChildNodes()) {
childNode = n.getLastChild();
removeNodes(childNode);
n.removeChild(childNode);
childNode = null;
}
n = null;
}
If I do that without setting the SVG document in JSVGCanvas
(m_oSVGCanvas.setSVGDocument(m_oSVGDocument);) it works. The memory isn't
increasing. If I try it with setting the SVG document in JSVGCanvas,
flushSVGDocument doesn't work, the memory is still increasing and I have the
following exception if I try to flush the SVG file:
java.lang.NullPointerException
at
org.apache.batik.bridge.AbstractGraphicsNodeBridge.handleDOMNodeRemovedEvent
(Unknown Source)
at
org.apache.batik.bridge.BridgeContext$DOMNodeRemovedEventListener.handleEven
t(Unknown Source)
at org.apache.batik.dom.events.EventSupport.fireEventListeners(Unknown
Source)
at org.apache.batik.dom.events.EventSupport.dispatchEvent(Unknown
Source)
at org.apache.batik.dom.AbstractNode.dispatchEvent(Unknown Source)
at
org.apache.batik.dom.AbstractParentNode.fireDOMNodeRemovedEvent(Unknown
Source)
at org.apache.batik.dom.AbstractParentNode.removeChild(Unknown Source)
at
ch.pmm.chartstudio.chartgen.DialogChart.removeNodes(DialogChart.java:208)
at
ch.pmm.chartstudio.chartgen.DialogChart.removeNodes(DialogChart.java:207)
at
ch.pmm.chartstudio.chartgen.DialogChart.removeNodes(DialogChart.java:207)
at
ch.pmm.chartstudio.chartgen.DialogChart.removeNodes(DialogChart.java:207)
at
ch.pmm.chartstudio.chartgen.DialogChart.removeNodes(DialogChart.java:207)
at
ch.pmm.chartstudio.chartgen.DialogChart.flushSVGDocument(DialogChart.java:19
3)
at
ch.pmm.chartstudio.chartwiz.PanelDialogProdJob_Button.actionPerformed(Dialog
ProdJob.java:460)
at
javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1445)
at
javax.swing.AbstractButton$ForwardActionEvents.actionPerformed(AbstractButto
n.java:1499)
at
javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:3
73)
at
javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:245)
at
javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener
.java:211)
at java.awt.Component.processMouseEvent(Component.java:3710)
at java.awt.Component.processEvent(Component.java:3539)
at java.awt.Container.processEvent(Container.java:1159)
at java.awt.Component.dispatchEventImpl(Component.java:2588)
at java.awt.Container.dispatchEventImpl(Container.java:1208)
at java.awt.Component.dispatchEvent(Component.java:2492)
at
java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:2451)
at
java.awt.LightweightDispatcher.processMouseEvent(Container.java:2216)
at java.awt.LightweightDispatcher.dispatchEvent(Container.java:2125)
at java.awt.Container.dispatchEventImpl(Container.java:1195)
at java.awt.Window.dispatchEventImpl(Window.java:923)
at java.awt.Component.dispatchEvent(Component.java:2492)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:334)
at
java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.ja
va:126)
at
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java
:93)
at java.awt.Dialog.show(Dialog.java:375)
at java.awt.Component.show(Component.java:941)
at java.awt.Component.setVisible(Component.java:898)
at
ch.pmm.chartstudio.chartwiz.DialogTableProdJob_Table.actionPerformed(DialogT
ableProdJob.java:150)
at ch.pmm.chartstudio.Panel1.actionEdit(Panel1.java:89)
at ch.pmm.chartstudio.Panel1.mouseClicked(Panel1.java:326)
at
java.awt.AWTEventMulticaster.mouseClicked(AWTEventMulticaster.java:206)
at
java.awt.AWTEventMulticaster.mouseClicked(AWTEventMulticaster.java:205)
at java.awt.Component.processMouseEvent(Component.java:3713)
at java.awt.Component.processEvent(Component.java:3539)
at java.awt.Container.processEvent(Container.java:1159)
at java.awt.Component.dispatchEventImpl(Component.java:2588)
at java.awt.Container.dispatchEventImpl(Container.java:1208)
at java.awt.Component.dispatchEvent(Component.java:2492)
at
java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:2451)
at
java.awt.LightweightDispatcher.processMouseEvent(Container.java:2230)
at java.awt.LightweightDispatcher.dispatchEvent(Container.java:2125)
at java.awt.Container.dispatchEventImpl(Container.java:1195)
at java.awt.Window.dispatchEventImpl(Window.java:923)
at java.awt.Component.dispatchEvent(Component.java:2492)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:334)
at
java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.ja
va:126)
at
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java
:93)
at java.awt.Dialog.show(Dialog.java:375)
at java.awt.Component.show(Component.java:941)
at java.awt.Component.setVisible(Component.java:898)
at
ch.pmm.chartstudio.chartstudio.ChartStudioFrame.jMenuEditChartWizard_actionP
erformed(ChartStudioFrame.java:147)
at
ch.pmm.chartstudio.chartstudio.ChartStudioFrame.actionPerformed(ChartStudioF
rame.java:124)
at
javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1445)
at
javax.swing.AbstractButton$ForwardActionEvents.actionPerformed(AbstractButto
n.java:1499)
at
javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:3
73)
at
javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:245)
at javax.swing.AbstractButton.doClick(AbstractButton.java:274)
at
javax.swing.plaf.basic.BasicMenuItemUI$MouseInputHandler.mouseReleased(Basic
MenuItemUI.java:882)
at java.awt.Component.processMouseEvent(Component.java:3710)
at java.awt.Component.processEvent(Component.java:3539)
at java.awt.Container.processEvent(Container.java:1159)
at java.awt.Component.dispatchEventImpl(Component.java:2588)
at java.awt.Container.dispatchEventImpl(Container.java:1208)
at java.awt.Component.dispatchEvent(Component.java:2492)
at
java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:2451)
at
java.awt.LightweightDispatcher.processMouseEvent(Container.java:2216)
at java.awt.LightweightDispatcher.dispatchEvent(Container.java:2125)
at java.awt.Container.dispatchEventImpl(Container.java:1195)
at java.awt.Window.dispatchEventImpl(Window.java:923)
at java.awt.Component.dispatchEvent(Component.java:2492)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:334)
at
java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.ja
va:126)
at
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java
:93)
at
java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:88)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:80)
I try it also with:
//--------------------------------------------------------------------------
// Flush SVG document
//--------------------------------------------------------------------------
public void flushSVGDocument() {
Node childNode = null;
SVGDocument oSVGDocument = m_oSVGCanvas.getSVGDocument();
if (oSVGDocument != null) {
SVGSVGElement s = oSVGDocument.getRootElement();
removeNodes(s);
}
oSVGDocument = null;
System.gc();
}
//--------------------------------------------------------------------------
// Flush Node
//--------------------------------------------------------------------------
private void removeNodes(Node n) {
Node childNode = null;
while (n.hasChildNodes()) {
childNode = n.getLastChild();
removeNodes(childNode);
n.removeChild(childNode);
childNode = null;
}
n = null;
}
But this causes the same exceptions.
I'm still trying to find a workaround for this memory overflow, but I don't
know what could be the solution. I can reproduce the memory overflow also in
Batik-Squiggle. Thomas E Deweese: I will send the SVG file I used for the
tests directly to you, its too large for the newsgroup. Is someone other
interested for the SVG file, please email me.
Thanks for help
Hans
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org