now something important is that mondrian is barely usable for us: DSM, package blueprint, torch are all slow. I would really like to see some pragmatic solutions to be found. Like not computing all the blocks all over the time.

Stef On Jun 15, 2010, at 12:43 PM, Tudor Girba wrote: _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

When I look to MOCanvas, I don't find any initialization of the concrete Canvas used . There is only a Method MOCanvas >> drawOn:, that then let a MORoot object call MORoot>>displayOn:, that then dispatch the work to each 'shape-class'. But I still don't find where the 'concrete' canvas is used (maybe I should wear glasses :)) 2010/6/15 Tudor Girba <tudor.girba(a)gmail.com> Hi, now something important is that mondrian is barely usable for us: DSM, package blueprint, torch are all slow. I would really like to see some pragmatic solutions to be found. Like not computing all the blocks all over the time. This is what we are already discussing, but until now it is not clear what exactly generates the slowness. I believe the problem comes from the edges, but we have to take a more systematic look. The other thing that has an impact is that right now Mondrian computes everything lazily, so even if the visualization appears, scrolling might still be problematic the first time you go through the entire picture. So, testing should also take this into account. Doru Stef On Jun 15, 2010, at 12:43 PM, Tudor Girba wrote: Hi Cyrille, The canvas is defined in MOCanvas. This canvas is embedded in MOBrowser and MOEasel, which in their turn create a StandardWindow that holds the MOCanvas. Just to inform the others, Cyrille is experimenting with adding the Athens canvas (which provides an abstraction over Cairo, Balloon and possibly others) behind Mondrian. Cheers, Doru On 15 Jun 2010, at 11:42, Cyrille Delaunay wrote: Hello, I have been looking a bit for the place where we set the canvas to use in Mondrian, but I didn't find. I know that all shapes are drawn on a FormCanvas, but there is no references to FormCanvas in mondrian classes. I just saw that there is a 'defaultCanvasClass' method in the class Form for example, so maybe such a method is use somewhere in the code. Does somoene know the way to set a new Canvas to Mondrian ? _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "Presenting is storytelling." _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "There are no old things, there are only old ways of looking at them." _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Ok. But, first, I don't why MOCanvas is a subclass of Morph (and not a subclass of Canvas) ? MOCanvas doesn't define any 'drawRectangle:' or 'drawSomething' methods, like usual canvas does. By setting some halt in the 'shape-classes' (MORectangleShape, MOEllipseShape), I saw that the method display:on: is called with a 'FormCanvas' as parameter. So somewhere in the code, somoene is telling to MOCanvas: drawOn: aFormCanvas. But it seems to not be in Mondrian 2010/6/15 Tudor Girba <tudor.girba(a)gmail.com> Hi, MOCanvas is the canvas, it is a subclass of Morph :). Doru On 15 Jun 2010, at 13:23, Cyrille Delaunay wrote: When I look to MOCanvas, I don't find any initialization of the concrete Canvas used . There is only a Method MOCanvas >> drawOn:, that then let a MORoot object call MORoot>>displayOn:, that then dispatch the work to each 'shape-class'. But I still don't find where the 'concrete' canvas is used (maybe I should wear glasses :)) 2010/6/15 Tudor Girba <tudor.girba(a)gmail.com> Hi, now something important is that mondrian is barely usable for us: DSM, package blueprint, torch are all slow. I would really like to see some pragmatic solutions to be found. Like not computing all the blocks all over the time. This is what we are already discussing, but until now it is not clear what exactly generates the slowness. I believe the problem comes from the edges, but we have to take a more systematic look. The other thing that has an impact is that right now Mondrian computes everything lazily, so even if the visualization appears, scrolling might still be problematic the first time you go through the entire picture. So, testing should also take this into account. Doru Stef On Jun 15, 2010, at 12:43 PM, Tudor Girba wrote: Hi Cyrille, The canvas is defined in MOCanvas. This canvas is embedded in MOBrowser and MOEasel, which in their turn create a StandardWindow that holds the MOCanvas. Just to inform the others, Cyrille is experimenting with adding the Athens canvas (which provides an abstraction over Cairo, Balloon and possibly others) behind Mondrian. Cheers, Doru On 15 Jun 2010, at 11:42, Cyrille Delaunay wrote: Hello, I have been looking a bit for the place where we set the canvas to use in Mondrian, but I didn't find. I know that all shapes are drawn on a FormCanvas, but there is no references to FormCanvas in mondrian classes. I just saw that there is a 'defaultCanvasClass' method in the class Form for example, so maybe such a method is use somewhere in the code. Does somoene know the way to set a new Canvas to Mondrian ? _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "Presenting is storytelling." _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "There are no old things, there are only old ways of looking at them." _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "One cannot do more than one can do." _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

That's exactly what I want to do: 'to pass the AthensCanvas into that drawOn: method. But I don't know how to do that,i don't know where to say: 'the default canvas to use now is RomeCanvas' 2010/6/15 Tudor Girba <tudor.girba(a)gmail.com> Hi Cyrille, Ok, I think I see where the confusion comes from. Every Morph is passed the actual Canvas in the drawOn: method. This is part of the rendering loop. What you want is to pass the AthensCanvas into that drawOn: method. Does this help? Doru On 15 Jun 2010, at 13:50, Cyrille Delaunay wrote: Ok. But, first, I don't why MOCanvas is a subclass of Morph (and not a subclass of Canvas) ? MOCanvas doesn't define any 'drawRectangle:' or 'drawSomething' methods, like usual canvas does. By setting some halt in the 'shape-classes' (MORectangleShape, MOEllipseShape), I saw that the method display:on: is called with a 'FormCanvas' as parameter. So somewhere in the code, somoene is telling to MOCanvas: drawOn: aFormCanvas. But it seems to not be in Mondrian 2010/6/15 Tudor Girba <tudor.girba(a)gmail.com> Hi, MOCanvas is the canvas, it is a subclass of Morph :). Doru On 15 Jun 2010, at 13:23, Cyrille Delaunay wrote: When I look to MOCanvas, I don't find any initialization of the concrete Canvas used . There is only a Method MOCanvas >> drawOn:, that then let a MORoot object call MORoot>>displayOn:, that then dispatch the work to each 'shape-class'. But I still don't find where the 'concrete' canvas is used (maybe I should wear glasses :)) 2010/6/15 Tudor Girba <tudor.girba(a)gmail.com> Hi, now something important is that mondrian is barely usable for us: DSM, package blueprint, torch are all slow. I would really like to see some pragmatic solutions to be found. Like not computing all the blocks all over the time. This is what we are already discussing, but until now it is not clear what exactly generates the slowness. I believe the problem comes from the edges, but we have to take a more systematic look. The other thing that has an impact is that right now Mondrian computes everything lazily, so even if the visualization appears, scrolling might still be problematic the first time you go through the entire picture. So, testing should also take this into account. Doru Stef On Jun 15, 2010, at 12:43 PM, Tudor Girba wrote: Hi Cyrille, The canvas is defined in MOCanvas. This canvas is embedded in MOBrowser and MOEasel, which in their turn create a StandardWindow that holds the MOCanvas. Just to inform the others, Cyrille is experimenting with adding the Athens canvas (which provides an abstraction over Cairo, Balloon and possibly others) behind Mondrian. Cheers, Doru On 15 Jun 2010, at 11:42, Cyrille Delaunay wrote: Hello, I have been looking a bit for the place where we set the canvas to use in Mondrian, but I didn't find. I know that all shapes are drawn on a FormCanvas, but there is no references to FormCanvas in mondrian classes. I just saw that there is a 'defaultCanvasClass' method in the class Form for example, so maybe such a method is use somewhere in the code. Does somoene know the way to set a new Canvas to Mondrian ? _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "Presenting is storytelling." _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "There are no old things, there are only old ways of looking at them." _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "One cannot do more than one can do." _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "Reasonable is what we are accustomed with." _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Hi, This is what we are already discussing, but until now it is not clear what exactly generates the slowness. I believe the problem comes from the edges, but we have to take a more systematic look. The other thing that has an impact is that right now Mondrian computes everything lazily, so even if the visualization appears, scrolling might still be problematic the first time you go through the entire picture. So, testing should also take this into account. Doru -- www.tudorgirba.com "There are no old things, there are only old ways of looking at them."

With the latest changes in Mondrian, Torch has a noticeable speed improvement (except one). I will perform tests and will let you know.

Veronica On 15 Jun 2010, at 13:25, Tudor Girba wrote: _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Doru Jannik said it several times - check the list. So do not tell him that he did not want to help. Stef On Jun 15, 2010, at 1:25 PM, Tudor Girba wrote: _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

+1 Alexandre _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

but the example proposed by jean-remi is exactly the same as the one proposed by jannik a while ago this is a complex case.

Stef On Jun 15, 2010, at 2:46 PM, Alexandre Bergel wrote: _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

In the Rome examples, we create a Canvas on a 'Form' (and it's on this Form that the drawing will be visible). In all RomeExample, the form on which we display is 'Display' (the class representing the display screen), but we can choose any other kind of Form. So basically , if you want to use a RomeCairoCanvas, you do: |canvas| canvas := RomeCairoCanvas on: Display (or any other kind of Form). canvas drawRectangle: ... .... canvas finish (=> to make the changes visible) Then if you choose to display on a basic Form, I guess you can integrate this Form to a Morph (?).

2010/6/15 Alexandre Bergel <alexandre.bergel(a)inria.fr> one proposed by jannik a while ago Yes, I will work on it. I have to identify where the slowness comes from, from Mondrian or package blueprint. Alexandre is difficult to find where problems are by looking at a very complex case. When the problems were raised, we did look into the issues, but it was just too difficult especially when we had multiple problems in the same time. multiple problems, there are some fixes, but there are still problems left. So, we have to dig deeper and we should do it more systematically by creating simpler cases that reproduce the problem. It's not an issue of "I told you so", it's an issue of "We need help to identify all problems" :). him that he did not want to help. blocks, you can easily get to quadratic algorithms. each]) size]. again, so N^2. complex graphs. And those people that have a direct interest in getting Mondrian fast would be good to help in this direction, because it can get difficult to understand the particularities of each model :) for us: DSM, package blueprint, torch are all slow. found. Like not computing all the blocks all over the time. not clear what exactly generates the slowness. I believe the problem comes from the edges, but we have to take a more systematic look. computes everything lazily, so even if the visualization appears, scrolling might still be problematic the first time you go through the entire picture. So, testing should also take this into account. in MOBrowser and MOEasel, which in their turn create a StandardWindow that holds the MOCanvas. adding the Athens canvas (which provides an abstraction over Cairo, Balloon and possibly others) behind Mondrian. canvas to use in Mondrian, but I didn't find. there is no references to FormCanvas in mondrian classes. the class Form for example, so maybe such a method is use somewhere in the code. at them." _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

In that case, it is easy to use Mondrian with RomeCairoCanvas in that case... something like "canvas drawOn: romeCairoCanvas" should do the thing. Alexandre On 16 Jun 2010, at 04:03, Cyrille Delaunay wrote: Form that the drawing will be visible). representing the display screen), but we can choose any other kind of Form. this Form to a Morph (?). proposed by jannik a while ago from Mondrian or package blueprint. difficult to find where problems are by looking at a very complex case. When the problems were raised, we did look into the issues, but it was just too difficult especially when we had multiple problems in the same time. problems, there are some fixes, but there are still problems left. So, we have to dig deeper and we should do it more systematically by creating simpler cases that reproduce the problem. It's not an issue of "I told you so", it's an issue of "We need help to identify all problems" :). that he did not want to help. blocks, you can easily get to quadratic algorithms. each]) size]. so N^2. graphs. And those people that have a direct interest in getting Mondrian fast would be good to help in this direction, because it can get difficult to understand the particularities of each model :) DSM, package blueprint, torch are all slow. Like not computing all the blocks all over the time. clear what exactly generates the slowness. I believe the problem comes from the edges, but we have to take a more systematic look. computes everything lazily, so even if the visualization appears, scrolling might still be problematic the first time you go through the entire picture. So, testing should also take this into account. MOBrowser and MOEasel, which in their turn create a StandardWindow that holds the MOCanvas. the Athens canvas (which provides an abstraction over Cairo, Balloon and possibly others) behind Mondrian. to use in Mondrian, but I didn't find. no references to FormCanvas in mondrian classes. class Form for example, so maybe such a method is use somewhere in the code. them." _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Hi Cyrille, I loaded the code from Athens and MondrianUsingRome, but when I spawn a visualization (like system complexity or blueprint) everything is white. Am I missing something? I did not have time to look into it in more details. Doru On 21 Jun 2010, at 11:55, Cyrille Delaunay wrote: Some news: -- www.tudorgirba.com "Every now and then stop and ask yourself if the war you're fighting is the right one." _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Ok, so if I try to understand a bit the structure: => MOCanvas is just the 'global' Morph (and so not really a canvas ?) that will contains all the elements's morphs => This global morph know the MORoot element . => This MORoot element know each sub-MONodeElement. => Then the MOCanvas Morph can be set to any MorphWindow (to the MOBrowser or MOEasel for example). => It's only when we try to open such a window, that we concretely 'draw' each node (dispatching the work to the corresponding MOShapes). => So the morphic library says to the MOCanvas: drawOn:, wich dispatch the work to the MORoot, wich dispatch to each MONode, which dispatch tho the corresponding MOShapes. Like alex said, the concrete canvas to use is provided by Morphic, and if no one should manually instantiate it, Morphic should also be modified to use by default the RomeCanvas instead of the current ones (?).

What seems to be sure, is that we can't specify easily a specific canvas to be used in mondrian

2010/6/15 Alexandre Bergel <alexandre.bergel(a)inria.fr> difficult to find where problems are by looking at a very complex case. When the problems were raised, we did look into the issues, but it was just too difficult especially when we had multiple problems in the same time. multiple problems, there are some fixes, but there are still problems left. So, we have to dig deeper and we should do it more systematically by creating simpler cases that reproduce the problem. It's not an issue of "I told you so", it's an issue of "We need help to identify all problems" :). +1 Alexandre that he did not want to help. blocks, you can easily get to quadratic algorithms. each]) size]. again, so N^2. graphs. And those people that have a direct interest in getting Mondrian fast would be good to help in this direction, because it can get difficult to understand the particularities of each model :) us: DSM, package blueprint, torch are all slow. found. Like not computing all the blocks all over the time. clear what exactly generates the slowness. I believe the problem comes from the edges, but we have to take a more systematic look. computes everything lazily, so even if the visualization appears, scrolling might still be problematic the first time you go through the entire picture. So, testing should also take this into account. MOBrowser and MOEasel, which in their turn create a StandardWindow that holds the MOCanvas. adding the Athens canvas (which provides an abstraction over Cairo, Balloon and possibly others) behind Mondrian. canvas to use in Mondrian, but I didn't find. is no references to FormCanvas in mondrian classes. the class Form for example, so maybe such a method is use somewhere in the code. them." _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

In fact you implemented like that reuse the mouse over and other from Morph. Because build it on the canvas direclty means that you should have build such infrastcuture? What cyrille measn is that if you would not rely on Morph but a canavs to draw then we could have just change the canvas. Now it means that we should be able to draw a morph with the new canvas and this is not clear that this is trivial

have a look in the rome examples.

_______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Ok, so if I try to understand a bit the structure: => MOCanvas is just the 'global' Morph (and so not really a canvas ?) that will contains all the elements's morphs => This global morph know the MORoot element . => This MORoot element know each sub-MONodeElement. => Then the MOCanvas Morph can be set to any MorphWindow (to the MOBrowser or MOEasel for example). => It's only when we try to open such a window, that we concretely 'draw' each node (dispatching the work to the corresponding MOShapes). => So the morphic library says to the MOCanvas: drawOn:, wich dispatch the work to the MORoot, wich dispatch to each MONode, which dispatch tho the corresponding MOShapes. Like alex said, the concrete canvas to use is provided by Morphic, and if no one should manually instantiate it, Morphic should also be modified to use by default the RomeCanvas instead of the current ones (?). What seems to be sure, is that we can't specify easily a specific canvas to be used in mondrian 2010/6/15 Alexandre Bergel <alexandre.bergel(a)inria.fr> +1 Alexandre _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Just to inform the others, Cyrille is experimenting with adding the Athens canvas (which provides an abstraction over Cairo, Balloon and possibly others) behind Mondrian.