Prevent relayouting of the chart on indicator change #485
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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
Codecov Report
@@ Coverage Diff @@
## master #485 +/- ##
=========================================
Coverage 53.63% 53.64%
- Complexity 7480 7484 +4
=========================================
Files 389 389
Lines 40952 40958 +6
Branches 6604 6604
=========================================
+ Hits 21965 21972 +7
- Misses 17404 17407 +3
+ Partials 1583 1579 -4
Continue to review full report at Codecov.
|
|
That fixed it. Good find 👍 |
ennerf
previously approved these changes
Feb 8, 2022
|
This pull request introduces 1 alert when merging 4456a66 into 03ab1a9 - view on LGTM.com new alerts:
|
ennerf
approved these changes
Feb 11, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Set the layout property of the indicator triangle to unmanaged s.t.
changes on the triangle will not invalidate the layout of its parent foreground pane.
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 for the
managedproperty:solves #476
@ennerf does this solve your indicator performance issue?
This might also apply to other nodes in the chart, especially with all the plugins that work on the overlay so we should check if there are more nodes to set to unmanaged.