> On 16 Dec 2015, at 12:28, Nicolai Hess <nicolaih...@gmail.com> wrote: > > > > 2015-12-16 12:10 GMT+01:00 Esteban Lorenzano <esteba...@gmail.com > <mailto:esteba...@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.ber...@me.com > > <mailto: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 > >> <mailto:b...@openinworld.com>> wrote: > >>> On Tue, Dec 8, 2015 at 6:17 AM, Peter Uhnak <i.uh...@gmail.com > >>> <mailto: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 > >>> <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-Layout.html > >>>> > >>>> <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 > >>>>>> <mailto: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> <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/> > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > > >
