Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Value indicator triggers re-rendering of datasets #476

Closed
ennerf opened this issue Jan 11, 2022 · 2 comments
Closed

Value indicator triggers re-rendering of datasets #476

ennerf opened this issue Jan 11, 2022 · 2 comments
Labels
bug

Comments

@ennerf
Copy link
Collaborator

ennerf commented Jan 11, 2022

Describe the bug
Moving a value indicator triggers a layout of the entire chart. This is a big performance hit for large datasets.

To Reproduce
Run ChartIndicatorSample and move the indicator

More Information
The problem seems to be that the marker gets added to the plot foreground (see AbstractSingleValueIndicator), which triggers a layout of the chart area.

Removing the marker makes it work as expected.

var indicator = new XValueIndicator(chart.getXAxis(), 0, "") {
    @Override
    protected void layoutMarker(double startX, double startY, double endX, double endY) {
        // don't add a marker to avoid re-rendering the chart area
    }
};
chart.getPlugins().add(indicator);

I'm not familiar enough with the scene graph layout. Is it possible to have it in the axis area without causing re-rendering? If not, do you think it would make sense to have a flag for hiding the marker for the few cases where it matters?
@ennerf ennerf added the bug label Jan 11, 2022
@wirew0rm
Copy link
Member

Hey, thanks for bringing this up, this was changed in 11.2.0 here because it was necessary to see to which axis an indicator belonged to when there were multiple axes. I guess there should be a way to make the node not trigger the relayout, but i'll have to investigate how to do that.

wirew0rm added a commit that referenced this issue Feb 8, 2022
@wirew0rm
Prevent relayouting of the chart on indicator change
a1cab45 
Set the layout property of the indicator triangle to unmanaged s.t.
changes on the triangle will not invalidate the layout of its parent.

Since the position of the triangle is already computed manually and
guaranteed to stay inside of the plot bounds, this should be the correct
solution here.

From the openjfx documentation:
> Defines whether or not this node's layout will be managed by it's parent.
> If the node is managed, it's parent will factor the node's geometry
> into its own preferred size and layoutBounds calculations and will lay it
> out during the scene's layout pass. If a managed node's layoutBounds changes,
> it will automatically trigger relayout up the scene-graph to the nearest
> layout root (which is typically the scene's root node).
>
> If the node is unmanaged, its parent will ignore the child in both preferred
> size computations and layout. Changes in layoutBounds will not trigger
> relayout above it. If an unmanaged node is of type Parent, it will act as a
> "layout root", meaning that calls to Parent.requestLayout() beneath it will
> cause only the branch rooted by the node to be relayed out, thereby isolating
> layout changes to that root and below. It's the application's responsibility
> to set the size and position of an unmanaged node.
>
> By default all nodes are managed.
https://openjfx.io/javadoc/17/javafx.graphics/javafx/scene/Node.html#managedProperty

solves #476
@wirew0rm wirew0rm mentioned this issue Feb 8, 2022
Merged
wirew0rm added a commit that referenced this issue Feb 11, 2022
@wirew0rm
Prevent relayouting of the chart on indicator change (#485)
138d362 
* Prevent relayouting of the chart on indicator change

Set the layout property of the indicator triangle to unmanaged s.t.
changes on the triangle will not invalidate the layout of its parent.

Since the position of the triangle is already computed manually and
guaranteed to stay inside of the plot bounds, this should be the correct
solution here.

The same is also applied for overlay nodes of all the other plugins.

From the openjfx documentation:
> Defines whether or not this node's layout will be managed by it's parent.
> If the node is managed, it's parent will factor the node's geometry
> into its own preferred size and layoutBounds calculations and will lay it
> out during the scene's layout pass. If a managed node's layoutBounds changes,
> it will automatically trigger relayout up the scene-graph to the nearest
> layout root (which is typically the scene's root node).
>
> If the node is unmanaged, its parent will ignore the child in both preferred
> size computations and layout. Changes in layoutBounds will not trigger
> relayout above it. If an unmanaged node is of type Parent, it will act as a
> "layout root", meaning that calls to Parent.requestLayout() beneath it will
> cause only the branch rooted by the node to be relayed out, thereby isolating
> layout changes to that root and below. It's the application's responsibility
> to set the size and position of an unmanaged node.
>
> By default all nodes are managed.
https://openjfx.io/javadoc/17/javafx.graphics/javafx/scene/Node.html#managedProperty

solves #476
@wirew0rm
Copy link
Member

solved in #485

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@wirew0rm @ennerf