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