Re: Skype meeting?

>> Sorry for coming back to you a bit late, the weather is not at its best and so am I. In addition, we are intending to create synectique during this month, that's quite an amount of paperwork.
>
> Good luck with that :-)
>
>> I would like to know the roadmap that you have in mind vis-a-visa the usage of Athens as the graphic back-end of Roassal for Pharo and how does it involve Mathieu's work? Because in another mail, I read that you have a student (Milton) who's working on something similar?
>
> Email is such a bad communication medium.
> Milton is working on Sunburst, a sophisticated and compact visualization to visualize hierarchies. He will demonstrate this at ESUG probably.
> Milton are Mathieu are not in competition, in no way.
>
> Roassal has a dedicated canvas that talks to Athens. We incrementally incorporate Mathieu's work in the mainstream of Roassal.

>> - A more general question. We can render 5K or 10K nodes with Roassal today but the problem is that its so slow that we cannot use it. How do you measure the increase in performance apart from merely a time factor because 10secs might just be as acceptable as 1sec if the user is informed. So, we can have two parts: first the display creation part, that's normal that some computations take time and then the interaction part, which should be optimized.
>
> Well... we microbench Roassal for the rendering and interaction.
>
>> - Do you want to revisit the announcements part in Roassal because we saw sometimes ago that some announcements in Roassal were not garbage-collected and stayed in the memory?
>
> Recently we have built a memory profiler and we spotted many places in Roassal that produces unnecessary instances. We probably generate too many announcements.
>
> Cheers,
> Alexandre
>
>
>
>>
>> On Wed, May 29, 2013 at 4:29 PM, Alexandre Bergel <[hidden email]> wrote:
>> Hi!
>>
>> Just got a nice discussion. We have reviewed what Mathieu has done so far. We also have pair programmed and incorporated his code in the main stream of Roassal. We also spotted some shortcoming in some of the layouts. Here are the notes I took about the things to do
>>
>> Mathieu:
>>        • Change the name of the package Roassal-Algorithm -> RoassalAlgorithm
>>        • Change the name of the package Roassal-New -> RoassalNew
>>        • Move the Bezier curve facilities in ROAbstractCanvas and ROPharoCanvas
>>        • Make ROVerticalCompactTree and radial tree take nodes size into account. For example the following code spot the problems:
>> view shape rectangle
>>         width: [ :c | c numberOfVariables * 6 ];
>>         height: #numberOfMethods.
>> view nodes: Collection withAllSubclasses.
>> view edgesFrom: #superclass.
>> view treeLayout.
>> view layout:  (ROVerticalCompactTree new horizontalGap: 5).
>>
>> view shape rectangle
>> size: #numberOfMethods.
>> view nodes: ROShape withAllSubclasses.
>> view edgesFrom: #superclass.
>> view radialTreeLayout.
>>
>>        • Remove the log methods in the class RORectanglePacking
>>        • Rename the class RORectanglePacking into RORectanglePackingLayout (easy to do :-)
>>
>>
>> What we do on our side:
>>        • Show what he is doing to the World
>>        • Include the implementation of Bezier Athens in Roassal
>>        • Include ROArc from Mathieu in ROAbstractCanvas. And then, in the Athens canvas, he should override the forthcoming method drawArc… with the Athens code
>>
>>
>> We also briefly discuss about the infrastructure to render, let's say 5000 or 10 000 000 nodes. Basically we need to balance the gain of speed with the accuracy. The whole question is to understand where and how.
>>
>> Cheers,
>> Alexandre
>>
>> On May 29, 2013, at 6:48 AM, Usman Bhatti <[hidden email]> wrote:
>>
>>>
>>>
>>>
>>> On Wed, May 29, 2013 at 12:36 PM, <[hidden email]> wrote:
>>> In fact I made a mistake, it is 14h30 CET.
>>>
>>> No problem, tell me when you start and I'll try to participate.
>>>
>>>
>>> Mathieu
>>>
>>>
>>>
>>
>> --
>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>> Alexandre Bergel  http://www.bergel.eu
>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>
>>
>>
>>
>
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>

>>> Sorry for coming back to you a bit late, the weather is not at its best and so am I. In addition, we are intending to create synectique during this month, that's quite an amount of paperwork.
>>
>> Good luck with that :-)
>>
>>> I would like to know the roadmap that you have in mind vis-a-visa the usage of Athens as the graphic back-end of Roassal for Pharo and how does it involve Mathieu's work? Because in another mail, I read that you have a student (Milton) who's working on something similar?
>>
>> Email is such a bad communication medium.
>> Milton is working on Sunburst, a sophisticated and compact visualization to visualize hierarchies. He will demonstrate this at ESUG probably.
>> Milton are Mathieu are not in competition, in no way.
>>
>> Roassal has a dedicated canvas that talks to Athens. We incrementally incorporate Mathieu's work in the mainstream of Roassal.
>
> are you working on using athens transformation into roassal?
> Because this will provide speed up.
>
>
>>> - do you see athens as just another canvas (in addition to morphic) where things are drawn? If that's the case, then to me it means that these optimizations would not be available in the
>>> Morphic part.
>>
>> Well. Can we do more than just have an Athens canvas? Athens does not handle event as far as I know.
>
> For now Athens is a rendering canvas. It is lowest part. Event are Morphic stuff.
>
>> If an animation support is offered for Athens, we will then try to use it (if it is faster than the one we have currently in Roassal).
>
> Athens will not support animation. Another framework will use athens to render animation. Igor showed me some sketches and this is promising.
>
>>
>>> - what are the potential speed up points that you see where Roassal can be improved apart from using Athens?
>>
>> No idea. So far, I haven't seen any speedup, but rendering in Athens is much nicer.
>
> But are you using athens transformation? Because this is what we should do.
>
>
>>> - A more general question. We can render 5K or 10K nodes with Roassal today but the problem is that its so slow that we cannot use it. How do you measure the increase in performance apart from merely a time factor because 10secs might just be as acceptable as 1sec if the user is informed. So, we can have two parts: first the display creation part, that's normal that some computations take time and then the interaction part, which should be optimized.
>>
>> Well... we microbench Roassal for the rendering and interaction.
>>
>>> - Do you want to revisit the announcements part in Roassal because we saw sometimes ago that some announcements in Roassal were not garbage-collected and stayed in the memory?
>>
>> Recently we have built a memory profiler and we spotted many places in Roassal that produces unnecessary instances. We probably generate too many announcements.
>>
>> Cheers,
>> Alexandre
>>
>>
>>
>>>
>>> On Wed, May 29, 2013 at 4:29 PM, Alexandre Bergel <[hidden email]> wrote:
>>> Hi!
>>>
>>> Just got a nice discussion. We have reviewed what Mathieu has done so far. We also have pair programmed and incorporated his code in the main stream of Roassal. We also spotted some shortcoming in some of the layouts. Here are the notes I took about the things to do
>>>
>>> Mathieu:
>>>       • Change the name of the package Roassal-Algorithm -> RoassalAlgorithm
>>>       • Change the name of the package Roassal-New -> RoassalNew
>>>       • Move the Bezier curve facilities in ROAbstractCanvas and ROPharoCanvas
>>>       • Make ROVerticalCompactTree and radial tree take nodes size into account. For example the following code spot the problems:
>>> view shape rectangle
>>>        width: [ :c | c numberOfVariables * 6 ];
>>>        height: #numberOfMethods.
>>> view nodes: Collection withAllSubclasses.
>>> view edgesFrom: #superclass.
>>> view treeLayout.
>>> view layout:  (ROVerticalCompactTree new horizontalGap: 5).
>>>
>>> view shape rectangle
>>> size: #numberOfMethods.
>>> view nodes: ROShape withAllSubclasses.
>>> view edgesFrom: #superclass.
>>> view radialTreeLayout.
>>>
>>>       • Remove the log methods in the class RORectanglePacking
>>>       • Rename the class RORectanglePacking into RORectanglePackingLayout (easy to do :-)
>>>
>>>
>>> What we do on our side:
>>>       • Show what he is doing to the World
>>>       • Include the implementation of Bezier Athens in Roassal
>>>       • Include ROArc from Mathieu in ROAbstractCanvas. And then, in the Athens canvas, he should override the forthcoming method drawArc… with the Athens code
>>>
>>>
>>> We also briefly discuss about the infrastructure to render, let's say 5000 or 10 000 000 nodes. Basically we need to balance the gain of speed with the accuracy. The whole question is to understand where and how.
>>>
>>> Cheers,
>>> Alexandre
>>>
>>> On May 29, 2013, at 6:48 AM, Usman Bhatti <[hidden email]> wrote:
>>>
>>>>
>>>>
>>>>
>>>> On Wed, May 29, 2013 at 12:36 PM, <[hidden email]> wrote:
>>>> In fact I made a mistake, it is 14h30 CET.
>>>>
>>>> No problem, tell me when you start and I'll try to participate.
>>>>
>>>>
>>>> Mathieu
>>>
>>> --
>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>> Alexandre Bergel  http://www.bergel.eu
>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>
>> --
>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>> Alexandre Bergel  http://www.bergel.eu
>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>