Weird rendering artefacts

[domenicquirl]

Plotting DoubleDataSets with an ErrorDataSetRenderer, I am seeing strange visual glitches like these:

At first I thought these happened when multiple series are drawn on top of each other, but there only one data set at these points. There are other data sets in the same chart, and the colour of the artefacts sometimes changes when the series in the chart change or when their order changes. So far I've not been able to find out how the colour is determined, e.g. it is not the colour of the topmost series. The artefacts appear even when all other series are hidden (not visible), in which case they seem to always appear in the original colour of the series. Weirdly, if I make only a single other data set visible in the chart, the colour changes, but to a third, different colour which is not that of either of the two visible data sets. Artefacts hide and re-appear together with their data set when I toggle its visibility, but are not present when I zoom in further (via the Zoomer plugin).

Environment:

• OS: Windows
• Java version: AdoptOpenJDK 15.0.2.7-hotspot
• JavaFx version: OpenJFX 15.0.1
• ChartFx version: 11.2.5

[RalphSteinhagen]

@domenicquirl do you have an MVP to reproduce these effects? That would help a lot for debugging.

[domenicquirl]

I spent some time on reproducing this and managed to catch it in a reasonably simplified chart:

It's very consistent if you zoom in on the first two periods and then adjust the window with to become smaller. When I set the scene width to 400 instead of 800 I can reproduce it with only the zoom and without changing anything about the window.

Note that this happens even if the cosine function is the only data set in the chart. Adding a sine function, it shows artefacts as well for me. I could not get the colour of the artefacts to switch though in this small example, probably because it is not very dynamic.

Java Code:

package com.mindmotiv.arttest.signalplot.chart;

import com.mindmotiv.arttest.signalplot.plugins.DataPointHoverInfo;

import de.gsi.chart.XYChart;
import de.gsi.chart.axes.spi.DefaultNumericAxis;
import de.gsi.chart.plugins.Panner;
import de.gsi.chart.plugins.Zoomer;
import de.gsi.chart.renderer.LineStyle;
import de.gsi.chart.renderer.spi.ErrorDataSetRenderer;
import de.gsi.dataset.testdata.spi.CosineFunction;
import javafx.application.Application;
import javafx.application.Platform;
import javafx.scene.Scene;
import javafx.scene.layout.StackPane;
import javafx.stage.Stage;

public class DemoChart extends Application {

	public static void main( String [] args ) {
		Application.launch( args );
	}

	@Override
	public void start( Stage primaryStage ) throws Exception {

		var xAxis = new DefaultNumericAxis();
		var yAxis = new DefaultNumericAxis();
		yAxis.setAutoRangePadding( 0.05 );

		var baseChart = new XYChart( xAxis, yAxis );
		baseChart.updateAxisRange();
		baseChart.setLegendVisible( false );

		var renderer = new ErrorDataSetRenderer();
		renderer.setPolyLineStyle( LineStyle.STAIR_CASE );
		renderer.getAxes().add( yAxis );
		baseChart.getRenderers().add( renderer );

		baseChart.getPlugins().addAll( new DataPointHoverInfo(), new Panner(), new Zoomer() );

		var cos = new CosineFunction( "cos", 500 );
		cos.setStyle( "strokeColor=darkblue;fillColor=darkblue;" );
		renderer.getDatasets().add( cos );
//		var sine = new SineFunction( "sin", 500 );
//		sine.setStyle( "strokeColor=red;fillColor=red;" );
//		renderer.getDatasets().add( sine );

		final Scene scene = new Scene( new StackPane( baseChart ), 400, 600 );

		String style = DemoChart.class.getResource( "Demo.css" ).toExternalForm();
		scene.getStylesheets().add( style );

		primaryStage.setTitle( getClass().getSimpleName() );
		primaryStage.setScene( scene );
		primaryStage.show();
		primaryStage.setOnCloseRequest( evt -> Platform.exit() );
	}

}

CSS:

* {
	-fx-font-size: 11;
	-fx-text-fill: #ededed;
}

.chart-plot-background {
	-fx-background: #323232; /*#202124;*/
}

.chart-datapoint-tooltip-label {
	-fx-background-color: #424242;
	-fx-border-color: #adadad;
	-fx-border-width: 1px;
}

.axis {
    -fx-tick-label-fill: #CC893A;
}

.chart-horizontal-grid-lines, .chart-vertical-grid-lines  {
	-fx-stroke: #353C42;/*#41454c; */
}

[LilRonin]

Your css code saved my lif 3rd time thx

[domenicquirl]

While working on #457 I've just seen it in the MultipleAxesSample after some zooming:

(it's a bit hard to see in the preview, if you open the image on its own the lines are less blurry)

[wirew0rm]

I can recommend the ErrorDataSetRendererStylingSample for such Investigations, because it has a lot of knobs for the Renderer. I could reproduce it there (Using the MIX_TRIGONOMETRIC datasets, increasing the number of samples and zooming in to a similar setting that you provided). Then you can disable the error surfaces or disable the point reduction algorithm.

I'm not completely sure if this is a bug in the data reduction algorithm, the ErrorDataSetRenderer or if it is just the result for this kind of data and data reduction settings (maybe the default threshold distance for reduction should be reduced?).
At least as a workaround you can disable the error surfaces or change the point reduction threshold.

[RalphSteinhagen]

@domenicquirl this is not a bug but by design. 😄

The ErrorDataSetRenderer performs a point reduction algorithm if the points overlap within a non-discernable 'n x n' pixel area (default is '5x5', but can be adjusted via minRequiredReductionSizeProperty) and replaces these points with a visual (-only) replacement at the mean position and adds some error-bars that correspond to the point-spread of the replaced points. This is a visual optimization only and disappears when zooming-in and can change when shifting the DataSet.

In the case of the (default) ErrorStyle.ERRORCOMBO error style these error bars (aka. whiskers) are converted to error surfaces which -- since there are apparently no other errors attached to the DataSet -- appear to look a bit strange since the default error surface is plotted with hashing and corresponding 'fillColor=...` (usually matched to the stroke colour).

If you want to change, you can opt for one of the following options:

• using ErrorStyle.ERRORBARS showing error bars instead of surfaces
• change the error surface fill style and color (e.g. to a solid fill)
• using ErrorStyle.NONE (<-> need to assess if this a valid choice in your use case)
• reduce the minRequiredReductionSizeProperty() value to e.g. '3' or even '1' (<-> performance penalty for large DataSets)
• disable the point reduction algorithm entirely (<-> even larger performance penalty)

The default ErrorDataSetRenderer parameters are optimised for large DataSets and a behaviour to follow common mathematical/scientific practices. Still, there are certainly corner use-cases where there are other constraints.

... feel free to experiment or adjust the above parameters to your needs.

Hope this helps and explains a bit your observations. Thanks again for your interest and for using chart-fx.

[domenicquirl]

Thank you both of you for taking the time! I could not get the artefacts to disappear with any setting for the minRequiredReductionSizeProperty, but they are not present when point reduction is disabled. It's a bit sad to lose this optimization, but I'm not too worried since we already compress input data before plotting where possible. The error indication I want to keep - it's not in yet, but I want to use that to display tolerance bounds around some of the data sets.

Note that I was not able to try a minRequiredReductionSize of 1, due to the following error:

Caused by: java.lang.ArrayIndexOutOfBoundsException: Index 1 out of bounds for length 1
	at de.gsi.chart.renderer.datareduction.DefaultDataReducer.reducePointsInternal(DefaultDataReducer.java:347)
	at de.gsi.chart.renderer.datareduction.DefaultDataReducer.reducePoints(DefaultDataReducer.java:83)
	at de.gsi.chart.renderer.spi.CachedDataPoints.reduce(CachedDataPoints.java:507)
	at de.gsi.chart.renderer.spi.ErrorDataSetRenderer.lambda$render$3(ErrorDataSetRenderer.java:236)
	at java.base/java.util.Optional.ifPresent(Optional.java:176)
	at de.gsi.chart.renderer.spi.ErrorDataSetRenderer.render(ErrorDataSetRenderer.java:234)
	at de.gsi.chart.XYChart.redrawCanvas(XYChart.java:433)
	at de.gsi.chart.Chart.layoutChildren(Chart.java:749)
	at javafx.graphics/javafx.scene.Parent.layout(Parent.java:1207)

Since you mentioned reducing the number to 1 this is probably not supposed to happen?

Anyways, I'll go ahead without point reduction for now and come back to this if it turns out the performance is indeed too noticeable. Thanks again for your help!

[RalphSteinhagen]

Since you mentioned reducing the number to 1 this is probably not supposed to happen?

No, it's not. Unfortunately, I cannot reproduce it using the ErrorDataSetRendererStylingSample. Do you have more details on this?

Please feel free to open another new issue (possibly with an MVP) if this error prevails.

[domenicquirl]

I thought I didn't, since I was only looking at the options you gave for handling the unwanted visuals and tried different combinations. But now that I think about it, I think it's because the chart contains a data set with just a single point (it marks the origin). If I change the CosineFunction data set in the reproduction above to a new DoubleDataSet("X").set(0, 0, 0) the error appears with the sample.

Hope this helps, I probably won't have much more time for this in the coming days since I am also moving this week. So my time outside of work is rather packed.