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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.