Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » GEF » [GEF4] Bad Performance on Scaling with larger amount of Nodes
[GEF4] Bad Performance on Scaling with larger amount of Nodes [message #1746384] Thu, 27 October 2016 21:19 Go to next message
Uwe Peuker is currently offline Uwe PeukerFriend
Messages: 5
Registered: September 2016
Junior Member
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 #1746385 is a reply to message #1746384] Thu, 27 October 2016 21:23 Go to previous messageGo to next message
Uwe Peuker is currently offline Uwe PeukerFriend
Messages: 5
Registered: September 2016
Junior Member
A simple test case:
https://github.com/frankbenoit/gef4.mvc.tutorial

In tutorial1 change the content of the model from one to 10000 rectangles and watch the zoom performance.
Adding the property listener for canvas.contenttransform.mxx and recalculating the stroke width of the rectangles is not usable.
Re: [GEF4] Bad Performance on Scaling with larger amount of Nodes [message #1746429 is a reply to message #1746385] Fri, 28 October 2016 14:27 Go to previous messageGo to next message
Matthias Wienand is currently offline Matthias WienandFriend
Messages: 163
Registered: March 2015
Senior Member
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
Re: [GEF4] Bad Performance on Scaling with larger amount of Nodes [message #1746474 is a reply to message #1746429] Sun, 30 October 2016 12:46 Go to previous messageGo to next message
Uwe Peuker is currently offline Uwe PeukerFriend
Messages: 5
Registered: September 2016
Junior Member
Hi Matthias,

I tried both approaches, individual listeners and storing a single listener (in my sample in the FXViewportChangePolicy). Both solutions are not satisfying.
The problem seems to be the call of the viusal.setStrokeWitdth() in many instances.

The exponential assumption is caused by the attempt to debug the behavior. It is only a hypothesis.

Please try the test case as described above. I doesn't found a solution to get a acceptable live zoom behaviour.
I will going to experiment further with graduated zooming or something, but i would be happy in every hint. The pressure is high because the release next year seems to be cancel the gef/draw2d modules ???
Re: [GEF4] Bad Performance on Scaling with larger amount of Nodes [message #1746483 is a reply to message #1746474] Sun, 30 October 2016 21:43 Go to previous messageGo to next message
Matthias Wienand is currently offline Matthias WienandFriend
Messages: 163
Registered: March 2015
Senior Member
Hi Uwe,

I will take a closer look at it (and performance in general, as there are some problems known for large numbers of visuals, e.g. Bugzillas #505634 and #506758 [1]). For now, I would suggest binding the strokeWidthProperty() of the relevant JavaFX Shapes to a single DoubleBinding that computes its value in dependence on the contentTransformProperty() of the InfiniteCanvas, possibly rounding, so that the stroke-width is not adjusted for minimal zoom changes.

[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=505634 and https://bugs.eclipse.org/bugs/show_bug.cgi?id=506758

Best regards,
Matthias
Re: [GEF4] Bad Performance on Scaling with larger amount of Nodes [message #1746636 is a reply to message #1746384] Wed, 02 November 2016 10:56 Go to previous messageGo to next message
Matthias Wienand is currently offline Matthias WienandFriend
Messages: 163
Registered: March 2015
Senior Member
Hi Uwe,

sorry, I just noticed that I overlooked your last question regarding the Oxygen release. No worries, the Oxygen release will still contain the GEF Legacy (i.e. 3.x) components. We are not planning to remove them. You can take a look at the recently published slides from the last EclipseCon [1] that contain information about the last maintenance release and the upcoming Oxygen release.

[1] http://www.slideshare.net/AlexanderNyssen/gef4-dot-oh-dot-oh?ref=https://www.linkedin.com/in/nyssen

Best regards,
Matthias
Re: [GEF4] Bad Performance on Scaling with larger amount of Nodes [message #1746815 is a reply to message #1746483] Fri, 04 November 2016 22:46 Go to previous message
Colin Sharples is currently offline Colin SharplesFriend
Messages: 90
Registered: July 2009
Location: Wellington, New Zealand
Member

That reminds me, I was going to put together an example to demonstrate some performance issues I hit some time ago. In particular anything involving calculation of intersections has issues. I will put together some test cases and file a bug or two.

Colin Sharples
CTG Games Ltd
Wellington, New Zealand
Previous Topic:Display Child outside ParentContainer
Next Topic:[Zest]
Goto Forum:
  


Current Time: Tue Nov 13 22:55:30 GMT 2018

Powered by FUDForum. Page generated in 0.02751 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top