-
Notifications
You must be signed in to change notification settings - Fork 93
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Roadmap to 11.3 #527
Comments
The library sounds promising - getting it was a little confusing at first. The readme has already the new maven-target ('io.fair-acc:chartfx:11.3.0'), which isn't released yet. The currently released version ( |
Exception in Application start method |
You are right of course but apparently the maintainers of this project are doing other things or got stampeded by a herd of buffalo or something |
Since the major points on the 11.3 milestone have now been addressed, the current state of the main branch will become the 11.3 release in the next days. It brings lots of (mostly internal) reworking that massively improves performance, reliability and maintainability, lot of the hard work there was done by ennerf (Florian Enner) The biggest user facing change is the move from the de.gsi.chart* package name to io.fair_acc.chart-fx.*. While it is a bit annoying it should be mostly mechanical renames. You can already test the main branch with the snapshot release as described in the README.md or wait for the imminent release. Let us know if you encounter any problems. |
Please make it possible to adjust line join and line cap for renderers and/or change the default values. |
@protogenes Can you provide an example and screenshot that show the problem with the default settings? The default renderers don't set those values, so as an initial workaround you should be able to globally modify the defaults, e.g., var chart = new XYChart(xAxis, yAxis);
var gc= chart.getCanvas().getGraphicsContext2D();
gc.setLineCap(StrokeLineCap.ROUND);
gc.setMiterLimit(1); If you need something more localized you could extend the renderer var renderer = new ErrorDataSetRenderer() {
@Override
protected void render(final GraphicsContext gc, final DataSet dataSet, final DataSetNode style) {
gc.save();
gc.setLineCap(StrokeLineCap.ROUND);
gc.setMiterLimit(1);
super.render(gc, dataSet, style);
gc.restore();
}
}; |
@ennerf thanks, I also used a custom renderer. public class Demo extends Application {
@Override
public void start(Stage primaryStage) throws Exception {
XYChart chart = new XYChart();
DefaultDataSet dataSet = new DefaultDataSet("miter demo",
new double[]{1, 2, 3},
new double[]{1, 2, 1},
3,
false);
dataSet.setStyle("-fx-line-width: 6"); // make it more obvious
BasicDataSetRenderer renderer = new BasicDataSetRenderer(dataSet);
chart.getRenderers().setAll(renderer);
chart.getXAxis().setAutoRanging(false);
chart.getXAxis().setMin(0);
chart.getXAxis().setMax(100);
chart.getYAxis().setAutoRanging(false);
chart.getYAxis().setMin(0);
chart.getYAxis().setMax(10);
primaryStage.setScene(new Scene(chart));
primaryStage.show();
}
} Produces the following render that makes it hard to read the maximum value. Our real issue looks like this: Another issue I encountered: StyleBuilder uses |
Thanks, the hex string was an oversight. What would you want the default values to be? |
Thanks for bringing this up @protogenes (would even have warranted a dedicated issue i guess.) From first impulse, a value of 1 seems to be reasonable, since that would from my understanding mean that the value would never exceed the linewidth, which would be what i would expect. Imo it would be sufficient to change it to a reasonable value if not someone else thinks of a usecase where it would have to be user modified. If you would prepare a PR to change it in the renderer and add some before after screenshots i would gladly merge that. |
I'm going with gc.setLineJoin(StrokeLineJoin.BEVEL);
gc.setLineCap(StrokeLineCap.BUTT); because when exceeding the miter limit the join will fall back to a bevel anyways and these differences/changes in representation might be irritating for our time series. (Think variance in data reduction causing pixels to flicker for live data) |
closing this since 11.3.0 is released now. It might take a few hours for it to be available on maven central search, but it's already available in the repository. |
git clone -b 11.2.7 git@github.com:fair-acc/chart-fx.git
git switch -c 11.2.7
Feel can debug earlier version then by
<dependency>
<groupId>de.gsi.math</groupId>
<artifactId>chartfx-math</artifactId>
<version>${chartfx.project.version}</version>
</dependency>
<!-- https://mvnrepository.com/artifact/de.gsi/microservice -->
<dependency>
<groupId>de.gsi</groupId>
<artifactId>microservice</artifactId>
<version>${chartfx.project.version}</version>
</dependency>
<!-- https://mvnrepository.com/artifact/org.controlsfx/controlsfx -->
<dependency>
<groupId>org.controlsfx</groupId>
<artifactId>controlsfx</artifactId>
<!-- <version>11.2.0</version>-->
<version>11.0.1</version>
</dependency>
|
This is the roadmap issue collecting issues potentially breaking API, which should be addressed for the 11.3 release.
This announcement is here to track progress, but also to collect feedback from the community and to catch potential problems for consumers of the library early on.
master
->main
to unify with our other repositoriesde.gsi
->io.fair_acc.chartfx
(change new github coordinate, pom-xml etc.)open question/idea: using https://github.com/ReactiveX/RxJava ?? `Flowable (primarily DataSetMath)The text was updated successfully, but these errors were encountered: