[Moose-dev] 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.

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?

- 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.

- what are the potential speed up points that you see where Roassal can be improved apart from using Athens?

- 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.

- 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?

On Wed, May 29, 2013 at 4:29 PM, Alexandre Bergel <alexandre.bergel(a)me.com> 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 <usman.bhatti(a)gmail.com> wrote: -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.