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.ber...@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 <b...@openinworld.com> wrote: >> >> On Tue, Dec 8, 2015 at 10:19 PM, Ben Coman <b...@openinworld.com> wrote: >>> On Tue, Dec 8, 2015 at 6:17 AM, Peter Uhnak <i.uh...@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-Layout.html >>>> >>>>> >>>>> Cheers, >>>>> Alejandro >>>>> >>>>>> On Dec 7, 2015, at 5:26 PM, Pablo Polanco <parop...@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 > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > >
