Zooming bug with XYStepRenderer (?) [JFreeChart 1.0.14]

[matgst]

I am currently performing some tests with different renderers and strokes. As I was zooming in & out I noticed some (at least for me) really strange behaviour.

When using an XYStepRenderer together with a user-defined BasicStroke (dotdash) the zooming behaviour at some point started to perform really bad. The CPU usage went straight up to the top and the javaw.exe process startet consuming over 1 GB of memory until finally it crashed with an OutOfMemory error.

What amazed me most was:

• It only occurs with a "dotdash" stroke together with XYStepRenderer/XYSplineRenderer

• Memory is not allocated on the managed heap according to JVisualVM (see image 1)

Image 1


To reproduce this behaviour run the application below and start zooming in. How deep you have to zoom? Check out image 2 to get an idea.

Image 2

Code: Select all

public class ZoomingBug {

	public static void main(String[] args) {
		XYSeries series = new XYSeries("series1");
		series.add(5, 3);
		series.add(4, 3);
		series.add(3, 2);
		XYSeriesCollection dataset = new XYSeriesCollection();
		dataset.addSeries(series);
		JFreeChart chart = ChartFactory.createXYLineChart("Chart", "X", "Y", dataset, PlotOrientation.VERTICAL, true, true, false);
		XYPlot plot = (XYPlot) chart.getPlot();

		// Problem only occurs when using XYStepRenderer or XYSplineRenderer together with a "dotdash-stroke"
		XYStepRenderer renderer = new XYStepRenderer();
		renderer.setSeriesStroke(0, new BasicStroke(1, BasicStroke.CAP_BUTT, BasicStroke.JOIN_BEVEL, 1.0f, new float[] {3 * 3, 3, 3, 3}, 0.0f));
		plot.setRenderer(renderer);

		ChartFrame frame = new ChartFrame("chart", chart);
		frame.pack();
		frame.setVisible(true);
	}
}

Has anyone an idea what this could be?

Thanks
Matthias

[John Matthews]

Using Mac OS X with Java 6, I see a pattern of progressively longer updates with each zoom. The critical one seems to saturate the event queue (solid green, instead of short segments on a yellow background):



But the expected sawtooth pattern of heap management remains normal:



I added code to construct the GUI on the event dispatch thread and started with an artificially small heap to enhance detail.

Code: Select all

$ java -Xms32m -Xmx48m -cp build/classes:jfreechart-1.0.14.jar:jcommon-1.0.17.jar ZoomingBug &

Code: Select all

public class ZoomingBug {
    public static void main(String[] args) {
        XYSeries series = new XYSeries("series1");
        series.add(5, 3);
        series.add(4, 3);
        series.add(3, 2);
        XYSeriesCollection dataset = new XYSeriesCollection();
        dataset.addSeries(series);
        final JFreeChart chart = ChartFactory.createXYLineChart(
            "Chart", "X", "Y", dataset, PlotOrientation.VERTICAL, true, true, false);
        XYPlot plot = (XYPlot) chart.getPlot();

        // Problem only occurs when using XYStepRenderer or XYSplineRenderer together with a "dotdash-stroke"
        XYStepRenderer renderer = new XYStepRenderer();
        renderer.setSeriesStroke(0, new BasicStroke(1, BasicStroke.CAP_BUTT,
            BasicStroke.JOIN_BEVEL, 1.0f, new float[]{3 * 3, 3, 3, 3}, 0.0f));
        plot.setRenderer(renderer);
        EventQueue.invokeLater(new Runnable() {

            @Override
            public void run() {
                ChartFrame frame = new ChartFrame("chart", chart);
                frame.pack();
                frame.setLocationRelativeTo(null);
                frame.setVisible(true);
            }
        });
    }
}

[matgst]

Hey John,

thanks for your reply.

I forgot to mention that I am using Windows 7 32-bit with Java 7.
But nonetheless I do not think this really matters.

Did you zoom in as deep as I did? Because I have noticed this pattern with longer updates too but
at that point it suddenly starts consuming lots and lots of memory, but NOT on the managed heap.

Could you (or someone else) try to reproduce this problem?

Thanks
Matthias

[John Matthews]

I tried (and failed) to match your zoom level. I didn't see a memory problem, even with an artificially small heap. The saturated event queue bogged the whole machine down until I killed the JVM. Sorry, I have no helpful insight.

Update: On a whim, I tried a different rendering engine, Apple's Quartz. The problem did not appear when zoomed as shown. This is an order of magnitude more than the level that you pictured and that triggered the problem using Sun/Oracle's stock engine. It also rendered normally, without the spurious baseline extension. This suggests that the problem is not intrinsic to JFreeChart.

Code: Select all

if (System.getProperty("os.name").startsWith("Mac OS X")) {
    System.setProperty("apple.awt.graphics.UseQuartz", "true");
}

[matgst]

Ok, thanks John.
This was another good hint. I also assume that the problem is not specific to JFreeChart but rather
a problem in the native AWT/Java2D code. But I think we do not know enough to write a bug report
for the Java guys.

However, this means to me that we will have to provide some workaround in order to avoid zooming
into such a deep level.

Cheers,
Matthias