Roassal Performance Issues when applying layout
Hello, we are Pablo Polanco and Jorge Ampuero and we are Computer Science students at Universidad de Chile. We are currently taking a course on Robotics Software Engineering dictated by Johan Fabry. We want to visualize a simple directed graph and we are experiencing performance issues when layouting our visualization in Roassal. We provide the report from the Time Profiler when we visualize 13 elements and 38 edges: http://pastebin.com/zsh8YFPx Should it take so much time? How could we improve it? Is there another more appropriate layout? Thanks in advance :) â
Hi, It is really difficult to help you just with a profile and without looking at your code. Even though, I have noticed that most of the time is used on calculating properties related to CompositeShapes (like position and encompassing rectangle). Would be possible for you to run the same code but replacing the CompositeShape by another less complex shape (like RTBox)? If this new experiment is fast, then the problem would be those 2 properties (position and encompassing rectangle) are too expensive, and therefore we should think how to optimize that code. I know that ForceLayout is not the fastest layout, but 59 seconds is too much for just 13 elements. Cheers, Alejandro
On Dec 7, 2015, at 5:26 PM, Pablo Polanco <paropoga@gmail.com> wrote:
Hello, we are Pablo Polanco and Jorge Ampuero and we are Computer Science students at Universidad de Chile.
We are currently taking a course on Robotics Software Engineering dictated by Johan Fabry.
We want to visualize a simple directed graph and we are experiencing performance issues when layouting our visualization in Roassal.
We provide the report from the Time Profiler when we visualize 13 elements and 38 edges: http://pastebin.com/zsh8YFPx <http://pastebin.com/zsh8YFPx>
Should it take so much time? How could we improve it? Is there another more appropriate layout?
Thanks in advance :)
<Screenshot from 2015-12-07 17:23:05.png> â
On 12/07, Alejandro Infante wrote:
Hi, It is really difficult to help you just with a profile and without looking at your code. Even though, I have noticed that most of the time is used on calculating properties related to CompositeShapes (like position and encompassing rectangle).
Would be possible for you to run the same code but replacing the CompositeShape by another less complex shape (like RTBox)? If this new experiment is fast, then the problem would be those 2 properties (position and encompassing rectangle) are too expensive, and therefore we should think how to optimize that code.
I know that ForceLayout is not the fastest layout, but 59 seconds is too much for just 13 elements.
The complexity should be nlog(n) per iteration. For such small diagram this should be pretty much instant. However from the profiler I can see that a _lot_ of time is spent in calculating the label size, which definitely shouldn't be this slow... If you want to look at the other layouts, look at this https://dl.dropboxusercontent.com/u/31543901/AgileVisualization/Layout/0106-...
Cheers, Alejandro
On Dec 7, 2015, at 5:26 PM, Pablo Polanco <paropoga@gmail.com> wrote:
Hello, we are Pablo Polanco and Jorge Ampuero and we are Computer Science students at Universidad de Chile.
We are currently taking a course on Robotics Software Engineering dictated by Johan Fabry.
We want to visualize a simple directed graph and we are experiencing performance issues when layouting our visualization in Roassal.
We provide the report from the Time Profiler when we visualize 13 elements and 38 edges: http://pastebin.com/zsh8YFPx <http://pastebin.com/zsh8YFPx>
Should it take so much time? How could we improve it? Is there another more appropriate layout?
Thanks in advance :)
<Screenshot from 2015-12-07 17:23:05.png> â
-- Peter
On Tue, Dec 8, 2015 at 6:17 AM, Peter Uhnak <i.uhnak@gmail.com> wrote:
On 12/07, Alejandro Infante wrote:
Hi, It is really difficult to help you just with a profile and without looking at your code. Even though, I have noticed that most of the time is used on calculating properties related to CompositeShapes (like position and encompassing rectangle).
Would be possible for you to run the same code but replacing the CompositeShape by another less complex shape (like RTBox)? If this new experiment is fast, then the problem would be those 2 properties (position and encompassing rectangle) are too expensive, and therefore we should think how to optimize that code.
I know that ForceLayout is not the fastest layout, but 59 seconds is too much for just 13 elements.
The complexity should be nlog(n) per iteration. For such small diagram this should be pretty much instant.
However from the profiler I can see that a _lot_ of time is spent in calculating the label size, which definitely shouldn't be this slow...
I had this problem with labels a while a go in Rossal 1 when using Unicode in a label. https://github.com/moosetechnology/moose/issues/898
From memory it came down to calculating the width of a unicode string. I think I hacked it in the rendering loop, such that the string width is cached along with a copy of the string. Next iteration if the string was the same return the cached value, otherwise recalculate. I think I discounted resetting the cache to nil when setting the label string due to inter thread races.
cheers -ben
If you want to look at the other layouts, look at this https://dl.dropboxusercontent.com/u/31543901/AgileVisualization/Layout/0106-...
Cheers, Alejandro
On Dec 7, 2015, at 5:26 PM, Pablo Polanco <paropoga@gmail.com> wrote:
Hello, we are Pablo Polanco and Jorge Ampuero and we are Computer Science students at Universidad de Chile.
We are currently taking a course on Robotics Software Engineering dictated by Johan Fabry.
We want to visualize a simple directed graph and we are experiencing performance issues when layouting our visualization in Roassal.
We provide the report from the Time Profiler when we visualize 13 elements and 38 edges: http://pastebin.com/zsh8YFPx <http://pastebin.com/zsh8YFPx>
Should it take so much time? How could we improve it? Is there another more appropriate layout?
Thanks in advance :)
<Screenshot from 2015-12-07 17:23:05.png>
-- Peter
On Tue, Dec 8, 2015 at 10:19 PM, Ben Coman <btc@openinworld.com> wrote:
On Tue, Dec 8, 2015 at 6:17 AM, Peter Uhnak <i.uhnak@gmail.com> wrote:
On 12/07, Alejandro Infante wrote:
Hi, It is really difficult to help you just with a profile and without looking at your code. Even though, I have noticed that most of the time is used on calculating properties related to CompositeShapes (like position and encompassing rectangle).
Would be possible for you to run the same code but replacing the CompositeShape by another less complex shape (like RTBox)? If this new experiment is fast, then the problem would be those 2 properties (position and encompassing rectangle) are too expensive, and therefore we should think how to optimize that code.
I know that ForceLayout is not the fastest layout, but 59 seconds is too much for just 13 elements.
The complexity should be nlog(n) per iteration. For such small diagram this should be pretty much instant.
However from the profiler I can see that a _lot_ of time is spent in calculating the label size, which definitely shouldn't be this slow...
I had this problem with labels a while a go in Rossal 1 when using Unicode in a label. https://github.com/moosetechnology/moose/issues/898
From memory it came down to calculating the width of a unicode string. I think I hacked it in the rendering loop, such that the string width is cached along with a copy of the string. Next iteration if the string was the same return the cached value, otherwise recalculate. I think I discounted resetting the cache to nil when setting the label string due to inter thread races.
cheers -ben
Spur should help also with WideString ~8 times speedup https://www.mail-archive.com/pharo-dev@lists.pharo.org/msg12397.html which we should be able to test soon... cheers -ben
If you want to look at the other layouts, look at this https://dl.dropboxusercontent.com/u/31543901/AgileVisualization/Layout/0106-...
Cheers, Alejandro
On Dec 7, 2015, at 5:26 PM, Pablo Polanco <paropoga@gmail.com> wrote:
Hello, we are Pablo Polanco and Jorge Ampuero and we are Computer Science students at Universidad de Chile.
We are currently taking a course on Robotics Software Engineering dictated by Johan Fabry.
We want to visualize a simple directed graph and we are experiencing performance issues when layouting our visualization in Roassal.
We provide the report from the Time Profiler when we visualize 13 elements and 38 edges: http://pastebin.com/zsh8YFPx <http://pastebin.com/zsh8YFPx>
Should it take so much time? How could we improve it? Is there another more appropriate layout?
Thanks in advance :)
<Screenshot from 2015-12-07 17:23:05.png>
-- Peter
Currently text in Roassal does not work with Spur: it is wrongly positioned, and does not appear sometime⦠I did not look into more detail. Cheers, Alexandre
On Dec 16, 2015, at 2:26 AM, Ben Coman <btc@openInWorld.com> wrote:
On Tue, Dec 8, 2015 at 10:19 PM, Ben Coman <btc@openinworld.com> wrote:
On Tue, Dec 8, 2015 at 6:17 AM, Peter Uhnak <i.uhnak@gmail.com> wrote:
On 12/07, Alejandro Infante wrote:
Hi, It is really difficult to help you just with a profile and without looking at your code. Even though, I have noticed that most of the time is used on calculating properties related to CompositeShapes (like position and encompassing rectangle).
Would be possible for you to run the same code but replacing the CompositeShape by another less complex shape (like RTBox)? If this new experiment is fast, then the problem would be those 2 properties (position and encompassing rectangle) are too expensive, and therefore we should think how to optimize that code.
I know that ForceLayout is not the fastest layout, but 59 seconds is too much for just 13 elements.
The complexity should be nlog(n) per iteration. For such small diagram this should be pretty much instant.
However from the profiler I can see that a _lot_ of time is spent in calculating the label size, which definitely shouldn't be this slow...
I had this problem with labels a while a go in Rossal 1 when using Unicode in a label. https://github.com/moosetechnology/moose/issues/898
From memory it came down to calculating the width of a unicode string. I think I hacked it in the rendering loop, such that the string width is cached along with a copy of the string. Next iteration if the string was the same return the cached value, otherwise recalculate. I think I discounted resetting the cache to nil when setting the label string due to inter thread races.
cheers -ben
Spur should help also with WideString ~8 times speedup https://www.mail-archive.com/pharo-dev@lists.pharo.org/msg12397.html
which we should be able to test soon... cheers -ben
If you want to look at the other layouts, look at this https://dl.dropboxusercontent.com/u/31543901/AgileVisualization/Layout/0106-...
Cheers, Alejandro
On Dec 7, 2015, at 5:26 PM, Pablo Polanco <paropoga@gmail.com> wrote:
Hello, we are Pablo Polanco and Jorge Ampuero and we are Computer Science students at Universidad de Chile.
We are currently taking a course on Robotics Software Engineering dictated by Johan Fabry.
We want to visualize a simple directed graph and we are experiencing performance issues when layouting our visualization in Roassal.
We provide the report from the Time Profiler when we visualize 13 elements and 38 edges: http://pastebin.com/zsh8YFPx <http://pastebin.com/zsh8YFPx>
Should it take so much time? How could we improve it? Is there another more appropriate layout?
Thanks in advance :)
<Screenshot from 2015-12-07 17:23:05.png>
-- Peter
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
thatâs most probably a bug in new FFI-NB backend. I would love some help here :) In any case, I will get back to FFI-NB as soon as I finish migration. Esteban
On 16 Dec 2015, at 12:03, Alexandre Bergel <alexandre.bergel@me.com> wrote:
Currently text in Roassal does not work with Spur: it is wrongly positioned, and does not appear sometime⦠I did not look into more detail.
Cheers, Alexandre
On Dec 16, 2015, at 2:26 AM, Ben Coman <btc@openInWorld.com> wrote:
On Tue, Dec 8, 2015 at 10:19 PM, Ben Coman <btc@openinworld.com> wrote:
On Tue, Dec 8, 2015 at 6:17 AM, Peter Uhnak <i.uhnak@gmail.com> wrote:
On 12/07, Alejandro Infante wrote:
Hi, It is really difficult to help you just with a profile and without looking at your code. Even though, I have noticed that most of the time is used on calculating properties related to CompositeShapes (like position and encompassing rectangle).
Would be possible for you to run the same code but replacing the CompositeShape by another less complex shape (like RTBox)? If this new experiment is fast, then the problem would be those 2 properties (position and encompassing rectangle) are too expensive, and therefore we should think how to optimize that code.
I know that ForceLayout is not the fastest layout, but 59 seconds is too much for just 13 elements.
The complexity should be nlog(n) per iteration. For such small diagram this should be pretty much instant.
However from the profiler I can see that a _lot_ of time is spent in calculating the label size, which definitely shouldn't be this slow...
I had this problem with labels a while a go in Rossal 1 when using Unicode in a label. https://github.com/moosetechnology/moose/issues/898
From memory it came down to calculating the width of a unicode string. I think I hacked it in the rendering loop, such that the string width is cached along with a copy of the string. Next iteration if the string was the same return the cached value, otherwise recalculate. I think I discounted resetting the cache to nil when setting the label string due to inter thread races.
cheers -ben
Spur should help also with WideString ~8 times speedup https://www.mail-archive.com/pharo-dev@lists.pharo.org/msg12397.html
which we should be able to test soon... cheers -ben
If you want to look at the other layouts, look at this https://dl.dropboxusercontent.com/u/31543901/AgileVisualization/Layout/0106-...
Cheers, Alejandro
On Dec 7, 2015, at 5:26 PM, Pablo Polanco <paropoga@gmail.com> wrote:
Hello, we are Pablo Polanco and Jorge Ampuero and we are Computer Science students at Universidad de Chile.
We are currently taking a course on Robotics Software Engineering dictated by Johan Fabry.
We want to visualize a simple directed graph and we are experiencing performance issues when layouting our visualization in Roassal.
We provide the report from the Time Profiler when we visualize 13 elements and 38 edges: http://pastebin.com/zsh8YFPx <http://pastebin.com/zsh8YFPx>
Should it take so much time? How could we improve it? Is there another more appropriate layout?
Thanks in advance :)
<Screenshot from 2015-12-07 17:23:05.png>
-- Peter
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
2015-12-16 12:10 GMT+01:00 Esteban Lorenzano <estebanlm@gmail.com>:
thatâs most probably a bug in new FFI-NB backend.
On windows (with spur-vm) most athens examples with transformations and/or text don't work (-> crash the vm).
I would love some help here :)
where to start? Is there a documentation about ffi/nb changes ( I hope so!). I saw some changes in Athens code but I don't understand it.
In any case, I will get back to FFI-NB as soon as I finish migration.
Esteban
On 16 Dec 2015, at 12:03, Alexandre Bergel <alexandre.bergel@me.com> wrote:
Currently text in Roassal does not work with Spur: it is wrongly positioned, and does not appear sometime⦠I did not look into more detail.
Cheers, Alexandre
On Dec 16, 2015, at 2:26 AM, Ben Coman <btc@openInWorld.com> wrote:
On Tue, Dec 8, 2015 at 10:19 PM, Ben Coman <btc@openinworld.com> wrote:
On Tue, Dec 8, 2015 at 6:17 AM, Peter Uhnak <i.uhnak@gmail.com> wrote:
On 12/07, Alejandro Infante wrote:
Hi, It is really difficult to help you just with a profile and without looking at your code. Even though, I have noticed that most of the time is used on calculating properties related to CompositeShapes (like position and encompassing rectangle).
Would be possible for you to run the same code but replacing the CompositeShape by another less complex shape (like RTBox)? If this new experiment is fast, then the problem would be those 2 properties (position and encompassing rectangle) are too expensive, and therefore we should think how to optimize that code.
I know that ForceLayout is not the fastest layout, but 59 seconds is too much for just 13 elements.
The complexity should be nlog(n) per iteration. For such small diagram this should be pretty much instant.
However from the profiler I can see that a _lot_ of time is spent in calculating the label size, which definitely shouldn't be this slow...
I had this problem with labels a while a go in Rossal 1 when using Unicode in a label. https://github.com/moosetechnology/moose/issues/898
From memory it came down to calculating the width of a unicode string. I think I hacked it in the rendering loop, such that the string width is cached along with a copy of the string. Next iteration if the string was the same return the cached value, otherwise recalculate. I think I discounted resetting the cache to nil when setting the label string due to inter thread races.
cheers -ben
Spur should help also with WideString ~8 times speedup https://www.mail-archive.com/pharo-dev@lists.pharo.org/msg12397.html
which we should be able to test soon... cheers -ben
If you want to look at the other layouts, look at this
https://dl.dropboxusercontent.com/u/31543901/AgileVisualization/Layout/0106-...
Cheers, Alejandro
On Dec 7, 2015, at 5:26 PM, Pablo Polanco <paropoga@gmail.com>
wrote:
Hello, we are Pablo Polanco and Jorge Ampuero and we are Computer
Science students at Universidad de Chile.
We are currently taking a course on Robotics Software Engineering
dictated by Johan Fabry.
We want to visualize a simple directed graph and we are
experiencing performance issues when layouting our visualization in Roassal.
We provide the report from the Time Profiler when we visualize 13
elements and 38 edges: http://pastebin.com/zsh8YFPx < http://pastebin.com/zsh8YFPx>
Should it take so much time? How could we improve it? Is there
another more appropriate layout?
Thanks in advance :)
<Screenshot from 2015-12-07 17:23:05.png>
-- Peter
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On 16 Dec 2015, at 12:28, Nicolai Hess <nicolaihess@gmail.com> wrote:
2015-12-16 12:10 GMT+01:00 Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com>>: thatâs most probably a bug in new FFI-NB backend.
On windows (with spur-vm) most athens examples with transformations and/or text don't work (-> crash the vm).
I would love some help here :)
where to start? Is there a documentation about ffi/nb changes ( I hope so!). I saw some changes in Athens code but I don't understand it.
I will do a blog post soon (â¢) :) cheers, Esteban
In any case, I will get back to FFI-NB as soon as I finish migration.
Esteban
On 16 Dec 2015, at 12:03, Alexandre Bergel <alexandre.bergel@me.com <mailto:alexandre.bergel@me.com>> wrote:
Currently text in Roassal does not work with Spur: it is wrongly positioned, and does not appear sometime⦠I did not look into more detail.
Cheers, Alexandre
On Dec 16, 2015, at 2:26 AM, Ben Coman <btc@openInWorld.com> wrote:
On Tue, Dec 8, 2015 at 10:19 PM, Ben Coman <btc@openinworld.com <mailto:btc@openinworld.com>> wrote:
On Tue, Dec 8, 2015 at 6:17 AM, Peter Uhnak <i.uhnak@gmail.com <mailto:i.uhnak@gmail.com>> wrote:
On 12/07, Alejandro Infante wrote:
Hi, It is really difficult to help you just with a profile and without looking at your code. Even though, I have noticed that most of the time is used on calculating properties related to CompositeShapes (like position and encompassing rectangle).
Would be possible for you to run the same code but replacing the CompositeShape by another less complex shape (like RTBox)? If this new experiment is fast, then the problem would be those 2 properties (position and encompassing rectangle) are too expensive, and therefore we should think how to optimize that code.
I know that ForceLayout is not the fastest layout, but 59 seconds is too much for just 13 elements.
The complexity should be nlog(n) per iteration. For such small diagram this should be pretty much instant.
However from the profiler I can see that a _lot_ of time is spent in calculating the label size, which definitely shouldn't be this slow...
I had this problem with labels a while a go in Rossal 1 when using Unicode in a label. https://github.com/moosetechnology/moose/issues/898 <https://github.com/moosetechnology/moose/issues/898>
From memory it came down to calculating the width of a unicode string. I think I hacked it in the rendering loop, such that the string width is cached along with a copy of the string. Next iteration if the string was the same return the cached value, otherwise recalculate. I think I discounted resetting the cache to nil when setting the label string due to inter thread races.
cheers -ben
Spur should help also with WideString ~8 times speedup https://www.mail-archive.com/pharo-dev@lists.pharo.org/msg12397.html <https://www.mail-archive.com/pharo-dev@lists.pharo.org/msg12397.html>
which we should be able to test soon... cheers -ben
If you want to look at the other layouts, look at this https://dl.dropboxusercontent.com/u/31543901/AgileVisualization/Layout/0106-... <https://dl.dropboxusercontent.com/u/31543901/AgileVisualization/Layout/0106-...>
Cheers, Alejandro
On Dec 7, 2015, at 5:26 PM, Pablo Polanco <paropoga@gmail.com <mailto:paropoga@gmail.com>> wrote:
Hello, we are Pablo Polanco and Jorge Ampuero and we are Computer Science students at Universidad de Chile.
We are currently taking a course on Robotics Software Engineering dictated by Johan Fabry.
We want to visualize a simple directed graph and we are experiencing performance issues when layouting our visualization in Roassal.
We provide the report from the Time Profiler when we visualize 13 elements and 38 edges: http://pastebin.com/zsh8YFPx <http://pastebin.com/zsh8YFPx> <http://pastebin.com/zsh8YFPx <http://pastebin.com/zsh8YFPx>>
Should it take so much time? How could we improve it? Is there another more appropriate layout?
Thanks in advance :)
<Screenshot from 2015-12-07 17:23:05.png>
-- Peter
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu <http://www.bergel.eu/> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
2015-12-16 12:28 GMT+01:00 Nicolai Hess <nicolaihess@gmail.com>:
2015-12-16 12:10 GMT+01:00 Esteban Lorenzano <estebanlm@gmail.com>:
thatâs most probably a bug in new FFI-NB backend.
On windows (with spur-vm) most athens examples with transformations and/or text don't work (-> crash the vm).
interestingly: AthensSurfaceExamples draw2Strings. -> crash FreeTypeFontProvider current updateFromSystem. AthensSurfaceExamples draw2Strings. -> works
I would love some help here :)
where to start? Is there a documentation about ffi/nb changes ( I hope so!). I saw some changes in Athens code but I don't understand it.
In any case, I will get back to FFI-NB as soon as I finish migration.
Esteban
On 16 Dec 2015, at 12:03, Alexandre Bergel <alexandre.bergel@me.com> wrote:
Currently text in Roassal does not work with Spur: it is wrongly positioned, and does not appear sometime⦠I did not look into more detail.
Cheers, Alexandre
On Dec 16, 2015, at 2:26 AM, Ben Coman <btc@openInWorld.com> wrote:
On Tue, Dec 8, 2015 at 10:19 PM, Ben Coman <btc@openinworld.com> wrote:
On Tue, Dec 8, 2015 at 6:17 AM, Peter Uhnak <i.uhnak@gmail.com> wrote:
On 12/07, Alejandro Infante wrote:
Hi, It is really difficult to help you just with a profile and without looking at your code. Even though, I have noticed that most of the time is used on calculating properties related to CompositeShapes (like position and encompassing rectangle).
Would be possible for you to run the same code but replacing the CompositeShape by another less complex shape (like RTBox)? If this new experiment is fast, then the problem would be those 2 properties (position and encompassing rectangle) are too expensive, and therefore we should think how to optimize that code.
I know that ForceLayout is not the fastest layout, but 59 seconds is too much for just 13 elements.
The complexity should be nlog(n) per iteration. For such small diagram this should be pretty much instant.
However from the profiler I can see that a _lot_ of time is spent in calculating the label size, which definitely shouldn't be this slow...
I had this problem with labels a while a go in Rossal 1 when using Unicode in a label. https://github.com/moosetechnology/moose/issues/898
From memory it came down to calculating the width of a unicode string. I think I hacked it in the rendering loop, such that the string width is cached along with a copy of the string. Next iteration if the string was the same return the cached value, otherwise recalculate. I think I discounted resetting the cache to nil when setting the label string due to inter thread races.
cheers -ben
Spur should help also with WideString ~8 times speedup https://www.mail-archive.com/pharo-dev@lists.pharo.org/msg12397.html
which we should be able to test soon... cheers -ben
If you want to look at the other layouts, look at this
https://dl.dropboxusercontent.com/u/31543901/AgileVisualization/Layout/0106-...
Cheers, Alejandro
On Dec 7, 2015, at 5:26 PM, Pablo Polanco <paropoga@gmail.com>
wrote:
Hello, we are Pablo Polanco and Jorge Ampuero and we are Computer
Science students at Universidad de Chile.
We are currently taking a course on Robotics Software Engineering
dictated by Johan Fabry.
We want to visualize a simple directed graph and we are
experiencing performance issues when layouting our visualization in Roassal.
We provide the report from the Time Profiler when we visualize 13
elements and 38 edges: http://pastebin.com/zsh8YFPx < http://pastebin.com/zsh8YFPx>
Should it take so much time? How could we improve it? Is there
another more appropriate layout?
Thanks in advance :)
<Screenshot from 2015-12-07 17:23:05.png>
-- Peter
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi Pablo, This is great that you contact the mailing list. You have apparently found a bug in the way composite shapes are implemented. I have fixed the problem by introducing a new class RTOptimizedForceBaseLayout. Please, update Roassal and try it. It should be super fast. Else, feel free to come to my office this Wednesday at 9:00 am :-) Cheers, Alexandre
On Dec 7, 2015, at 5:26 PM, Pablo Polanco <paropoga@gmail.com> wrote:
Hello, we are Pablo Polanco and Jorge Ampuero and we are Computer Science students at Universidad de Chile.
We are currently taking a course on Robotics Software Engineering dictated by Johan Fabry.
We want to visualize a simple directed graph and we are experiencing performance issues when layouting our visualization in Roassal.
We provide the report from the Time Profiler when we visualize 13 elements and 38 edges: http://pastebin.com/zsh8YFPx
Should it take so much time? How could we improve it? Is there another more appropriate layout?
Thanks in advance :)
<Screenshot from 2015-12-07 17:23:05.png> â
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
participants (7)
-
Alejandro Infante -
Alexandre Bergel -
Ben Coman -
Esteban Lorenzano -
Nicolai Hess -
Pablo Polanco -
Peter Uhnak