| [GEF4] Bad Performance on Scaling with larger amount of Nodes [message #1746384] |
Thu, 27 October 2016 17:19  |
Eclipse User |
|
|
|
In my use case I have many thousands of parts.
They are necessary because almost every of them has to be animated individually (actually a presentation of a geographical network)
Zooming the FXViewer canvas using the FXPanOrZoomPolicy results in a very bad performance.
Additional the parts have to keep a constant strokewidth, so on every zoom event the strokewidth has to be recalculated regarding the actual content transformation (zoom level) of the canvas.
Setting the stroke width seems to result in a exponential increase of the effort, because every change of the stroke width leads to a recalculation of the hole canvas, including all parts.
Is there another possibility to keep the stroke width of a Shape or Curve on a constant value on the screen independent from the zoom level of the canvas?
I tried:
- adding a individuell FXViewportChangePolicy and
- adding a listener on the content transformation mxx - property.
Many thanks
Uwe
|
|
|
|
| Re: [GEF4] Bad Performance on Scaling with larger amount of Nodes [message #1746429 is a reply to message #1746385] |
Fri, 28 October 2016 10:27  |
| Eclipse User |
|
|
|
Hi Uwe,
if I understand correctly, you are using individual listeners to keep the stroke widths of all parts constant while zooming. However, you could centralize the transformation listener by using one centralized DoubleProperty that computes the stroke-width in response to contentTransform changes. The individual stroke-width properties could then be bound to the centralized property.
> Setting the stroke width seems to result in a exponential increase of the effort, because every change of the stroke width leads to a recalculation of the hole canvas, including all parts.
I do not quite understand the "recalculation" of the parts/canvas. A part can be refreshed to adapt its visualization to its content, but this should only be done in response to content changes. Would you please explain the observed behavior more precisely?
There should not be a recalculation that is is triggered by the stroke width, except for the positioning of feedback or handles, and the content-bounds of the canvas (which are only updated if the bounds of a visual at the edge of the content-bounds is changed).
Best regards,
Matthias
|
|
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.05308 seconds
Home