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 ?
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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Presenting is storytelling."
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:
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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Presenting is storytelling."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Presenting is storytelling."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@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."
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@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Presenting is storytelling."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Presenting is storytelling."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"One cannot do more than one can do."
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@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@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Presenting is storytelling."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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@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@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Presenting is storytelling."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Reasonable is what we are accustomed with."
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@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@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@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Presenting is storytelling."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
I see.
How do you do it in the examples you showed me?
Let's start from there and we move up
Doru
On 15 Jun 2010, at 14:03, Cyrille Delaunay wrote:
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@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@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@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Presenting is storytelling."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"It's not how it is, it is how we see it."
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'
Cyrille, the instance of the form canvas is provided by Morphic. This is not something one should manually instantiate. MOCanvas is a simple morph that recursively display elements. It is not a substitute of FormCanvas or something.
Cheers, Alexandre
2010/6/15 Tudor Girba tudor.girba@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@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@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Presenting is storytelling."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
One more thing.
It can also be that when you have expensive traversals in your blocks, you can easily get to quadratic algorithms.
For example, suppose you have something like this:
view shape height: [:each | (classes select: [:target | target invokes: each]) size]. view nodes: classes
In this case, for each class, you would traverse all classes again, so N^2.
That is why we need canonical examples first that expose 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 :)
Cheers, Doru
On 15 Jun 2010, at 13:13, Tudor Girba wrote:
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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Presenting is storytelling."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@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."
-- www.tudorgirba.com
"In a world where everything is moving ever faster, one might have better chances to win by moving slower."
I am also sure the problem comes from the edges (even thought i have not those quadratic searches). But yes, you are right... we need cases that expose the problem...
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:
One more thing.
It can also be that when you have expensive traversals in your blocks, you can easily get to quadratic algorithms.
For example, suppose you have something like this:
view shape height: [:each | (classes select: [:target | target invokes: each]) size]. view nodes: classes
In this case, for each class, you would traverse all classes again, so N^2.
That is why we need canonical examples first that expose 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 :)
Cheers, Doru
On 15 Jun 2010, at 13:13, Tudor Girba wrote:
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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Presenting is storytelling."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@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."
-- www.tudorgirba.com
"In a world where everything is moving ever faster, one might have better chances to win by moving slower."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
With the latest changes in Mondrian, Torch has a noticeable speed improvement (except one). I will perform tests and will let you know.
Yes please. I will work on Jean-Rémy case.
Alexandre
Veronica
On 15 Jun 2010, at 13:25, Tudor Girba wrote:
One more thing.
It can also be that when you have expensive traversals in your blocks, you can easily get to quadratic algorithms.
For example, suppose you have something like this:
view shape height: [:each | (classes select: [:target | target invokes: each]) size]. view nodes: classes
In this case, for each class, you would traverse all classes again, so N^2.
That is why we need canonical examples first that expose 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 :)
Cheers, Doru
On 15 Jun 2010, at 13:13, Tudor Girba wrote:
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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Presenting is storytelling."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@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."
-- www.tudorgirba.com
"In a world where everything is moving ever faster, one might have better chances to win by moving slower."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@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:
One more thing.
It can also be that when you have expensive traversals in your blocks, you can easily get to quadratic algorithms.
For example, suppose you have something like this:
view shape height: [:each | (classes select: [:target | target invokes: each]) size]. view nodes: classes
In this case, for each class, you would traverse all classes again, so N^2.
That is why we need canonical examples first that expose 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 :)
Cheers, Doru
On 15 Jun 2010, at 13:13, Tudor Girba wrote:
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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Presenting is storytelling."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@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."
-- www.tudorgirba.com
"In a world where everything is moving ever faster, one might have better chances to win by moving slower."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Hi Stef,
Who said that? :)
I did not say that he did not say anything. I just said that it 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.
Now we are in the situation in which multiple people noticed 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" :).
Doru
On 15 Jun 2010, at 14:01, Stéphane Ducasse wrote:
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:
One more thing.
It can also be that when you have expensive traversals in your blocks, you can easily get to quadratic algorithms.
For example, suppose you have something like this:
view shape height: [:each | (classes select: [:target | target invokes: each]) size]. view nodes: classes
In this case, for each class, you would traverse all classes again, so N^2.
That is why we need canonical examples first that expose 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 :)
Cheers, Doru
On 15 Jun 2010, at 13:13, Tudor Girba wrote:
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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Presenting is storytelling."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@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."
-- www.tudorgirba.com
"In a world where everything is moving ever faster, one might have better chances to win by moving slower."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Sometimes the best solution is not the best solution."
I did not say that he did not say anything. I just said that it 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.
Now we are in the situation in which multiple people noticed 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
On 15 Jun 2010, at 14:01, Stéphane Ducasse wrote:
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:
One more thing.
It can also be that when you have expensive traversals in your blocks, you can easily get to quadratic algorithms.
For example, suppose you have something like this:
view shape height: [:each | (classes select: [:target | target invokes: each]) size]. view nodes: classes
In this case, for each class, you would traverse all classes again, so N^2.
That is why we need canonical examples first that expose 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 :)
Cheers, Doru
On 15 Jun 2010, at 13:13, Tudor Girba wrote:
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@iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Presenting is storytelling."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@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."
-- www.tudorgirba.com
"In a world where everything is moving ever faster, one might have better chances to win by moving slower."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Sometimes the best solution is not the best solution."
Moose-dev mailing list Moose-dev@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:
I did not say that he did not say anything. I just said that it 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.
Now we are in the situation in which multiple people noticed 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
On 15 Jun 2010, at 14:01, Stéphane Ducasse wrote:
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:
One more thing.
It can also be that when you have expensive traversals in your blocks, you can easily get to quadratic algorithms.
For example, suppose you have something like this:
view shape height: [:each | (classes select: [:target | target invokes: each]) size]. view nodes: classes
In this case, for each class, you would traverse all classes again, so N^2.
That is why we need canonical examples first that expose 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 :)
Cheers, Doru
On 15 Jun 2010, at 13:13, Tudor Girba wrote:
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@iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > > "Presenting is storytelling." > > _______________________________________________ > Moose-dev mailing list > Moose-dev@iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@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."
-- www.tudorgirba.com
"In a world where everything is moving ever faster, one might have better chances to win by moving slower."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Sometimes the best solution is not the best solution."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Yes, it is. I never said it is a good case.
But, what are we arguing here about? Let's just focus on the problem, please :)
Doru
On 15 Jun 2010, at 16:33, Stéphane Ducasse wrote:
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:
I did not say that he did not say anything. I just said that it 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.
Now we are in the situation in which multiple people noticed 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
On 15 Jun 2010, at 14:01, Stéphane Ducasse wrote:
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:
One more thing.
It can also be that when you have expensive traversals in your blocks, you can easily get to quadratic algorithms.
For example, suppose you have something like this:
view shape height: [:each | (classes select: [:target | target invokes: each]) size]. view nodes: classes
In this case, for each class, you would traverse all classes again, so N^2.
That is why we need canonical examples first that expose 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 :)
Cheers, Doru
On 15 Jun 2010, at 13:13, Tudor Girba wrote:
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@iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> www.tudorgirba.com >> >> "Presenting is storytelling." >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev@iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > _______________________________________________ > Moose-dev mailing list > Moose-dev@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."
-- www.tudorgirba.com
"In a world where everything is moving ever faster, one might have better chances to win by moving slower."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Sometimes the best solution is not the best solution."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Live like you mean it."
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.
Yes, I will work on it. I have to identify where the slowness comes from, from Mondrian or package blueprint.
Alexandre
Stef
On Jun 15, 2010, at 2:46 PM, Alexandre Bergel wrote:
I did not say that he did not say anything. I just said that it 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.
Now we are in the situation in which multiple people noticed 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
On 15 Jun 2010, at 14:01, Stéphane Ducasse wrote:
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:
One more thing.
It can also be that when you have expensive traversals in your blocks, you can easily get to quadratic algorithms.
For example, suppose you have something like this:
view shape height: [:each | (classes select: [:target | target invokes: each]) size]. view nodes: classes
In this case, for each class, you would traverse all classes again, so N^2.
That is why we need canonical examples first that expose 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 :)
Cheers, Doru
On 15 Jun 2010, at 13:13, Tudor Girba wrote:
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@iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> www.tudorgirba.com >> >> "Presenting is storytelling." >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev@iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > _______________________________________________ > Moose-dev mailing list > Moose-dev@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."
-- www.tudorgirba.com
"In a world where everything is moving ever faster, one might have better chances to win by moving slower."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Sometimes the best solution is not the best solution."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Hello,
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@inria.fr
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.
Yes, I will work on it. I have to identify where the slowness comes from, from Mondrian or package blueprint.
Alexandre
Stef
On Jun 15, 2010, at 2:46 PM, Alexandre Bergel wrote:
I did not say that he did not say anything. I just said that it 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.
Now we are in the situation in which multiple people noticed 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
On 15 Jun 2010, at 14:01, Stéphane Ducasse wrote:
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:
One more thing.
It can also be that when you have expensive traversals in your
blocks, you can easily get to quadratic algorithms.
For example, suppose you have something like this:
view shape height: [:each | (classes select: [:target | target invokes: each])
size].
view nodes: classes
In this case, for each class, you would traverse all classes again,
so N^2.
That is why we need canonical examples first that expose 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 :)
Cheers, Doru
On 15 Jun 2010, at 13:13, Tudor Girba wrote:
> 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@iam.unibe.ch >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> -- >>> www.tudorgirba.com >>> >>> "Presenting is storytelling." >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev@iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev@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."
> > >
-- www.tudorgirba.com
"In a world where everything is moving ever faster, one might have better chances to win by moving slower."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Sometimes the best solution is not the best solution."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Hi Cyrille,
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 ofForm).
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 (?).
Exactly. You should be able to have a Morph that has the Form you want, and that in turn draws on the type of canvas you want. I am not very knowledgeable in this area, but I think these methods could be a starting point:
Morph>>imageForm Morph>>imageForm: depth forRectangle: rect
If you manage to do this, then you probably need a new MOCanvas, or at least you need to parameterize the existing one. Just a note, the "canvas" in MOCanvas is not the same as the "canvas" in "RomeCairoCanvas". The MOCanvas comes from the canvas on which Mondrian (the painter) paints :), while the other one is a lower level one.
Cheers, Doru
2010/6/15 Alexandre Bergel alexandre.bergel@inria.fr
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.
Yes, I will work on it. I have to identify where the slowness comes from, from Mondrian or package blueprint.
Alexandre
Stef
On Jun 15, 2010, at 2:46 PM, Alexandre Bergel wrote:
I did not say that he did not say anything. I just said that it
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.
Now we are in the situation in which multiple people noticed
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
On 15 Jun 2010, at 14:01, Stéphane Ducasse wrote:
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:
One more thing.
It can also be that when you have expensive traversals in your
blocks, you can easily get to quadratic algorithms.
For example, suppose you have something like this:
view shape height: [:each | (classes select: [:target | target invokes:
each]) size].
view nodes: classes
In this case, for each class, you would traverse all classes
again, so N^2.
That is why we need canonical examples first that expose
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 :)
Cheers, Doru
On 15 Jun 2010, at 13:13, Tudor Girba wrote:
> 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@iam.unibe.ch >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> -- >>> www.tudorgirba.com >>> >>> "Presenting is storytelling." >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev@iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev@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."
> > >
-- www.tudorgirba.com
"In a world where everything is moving ever faster, one might have better chances to win by moving slower."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Sometimes the best solution is not the best solution."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Next time you see your life passing by, say 'hi' and get to know her."
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:
Hello,
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@inria.fr
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.
Yes, I will work on it. I have to identify where the slowness comes from, from Mondrian or package blueprint.
Alexandre
Stef
On Jun 15, 2010, at 2:46 PM, Alexandre Bergel wrote:
I did not say that he did not say anything. I just said that it 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.
Now we are in the situation in which multiple people noticed 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
On 15 Jun 2010, at 14:01, Stéphane Ducasse wrote:
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:
One more thing.
It can also be that when you have expensive traversals in your blocks, you can easily get to quadratic algorithms.
For example, suppose you have something like this:
view shape height: [:each | (classes select: [:target | target invokes: each]) size]. view nodes: classes
In this case, for each class, you would traverse all classes again, so N^2.
That is why we need canonical examples first that expose 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 :)
Cheers, Doru
On 15 Jun 2010, at 13:13, Tudor Girba wrote:
> 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@iam.unibe.ch >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> -- >>> www.tudorgirba.com >>> >>> "Presenting is storytelling." >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev@iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev@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." > > >
-- www.tudorgirba.com
"In a world where everything is moving ever faster, one might have better chances to win by moving slower."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Sometimes the best solution is not the best solution."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Some news:
* I still do not know where the 'concrete canvas' from Morphic is passed as argument to a MOCanvas. Try to put a 'halt' in MOCanvas>>drawOn: and you will see a long list of indirections that never ends (if your image is not yet frozen ;)). I just know that this is a FormCanvas that is passed. I also try to replace all references in pharo of FormCanvas by RomeBalloonCanvas, but this is still a FormCanvas that is passed to MOCanvas>>drawOn:. Therefore I didn't find any good solution to be able to switch between one kind of canvas to another kind. The MOCanvas is a morph, and I am not able to control its opening.
* What I have been able to do, is to modify the MOBrowser to not add the MOCanvas in the browser, but an ImageMorph built throught the MOCanvas>>drawOn: method (setting myself a RomeBalloonCanvas as parameter). It works, but as an image morph, you will not be able to interact (like with the usual MOCanvas morph) . But you can already see how the visializations are drawn by basically replacing the formCanvas by a RomeBalloonCanvas. For simple visualization (like DistributionMap for example) , there is no big changes. So to try it, first, load last Version ofAthens: www.squeaksource.com/Athens Then the last version of Mondrian in: www.squeaksource.com/MondrianUsingRome And then open any visualization (in the same way that you usally do)
2010/6/16 Alexandre Bergel alexandre.bergel@inria.fr
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:
Hello,
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@inria.fr
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.
Yes, I will work on it. I have to identify where the slowness comes from,
from Mondrian or package blueprint.
Alexandre
Stef
On Jun 15, 2010, at 2:46 PM, Alexandre Bergel wrote:
I did not say that he did not say anything. I just said that it 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.
Now we are in the situation in which multiple people noticed 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
On 15 Jun 2010, at 14:01, Stéphane Ducasse wrote:
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:
> One more thing. > > It can also be that when you have expensive traversals in your
blocks, you can easily get to quadratic algorithms.
> > For example, suppose you have something like this: > > view shape > height: [:each | (classes select: [:target | target invokes:
each]) size].
> view nodes: classes > > In this case, for each class, you would traverse all classes again,
so N^2.
> > That is why we need canonical examples first that expose 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 :)
> > Cheers, > Doru > > > On 15 Jun 2010, at 13:13, Tudor Girba wrote: > >> 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@iam.unibe.ch >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> >>>> -- >>>> www.tudorgirba.com >>>> >>>> "Presenting is storytelling." >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev@iam.unibe.ch >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev@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."
>> >> >> > > -- > www.tudorgirba.com > > "In a world where everything is moving ever faster, > one might have better chances to win by moving slower." > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev@iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Sometimes the best solution is not the best solution."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@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:
- I still do not know where the 'concrete canvas' from Morphic is
passed as argument to a MOCanvas. Try to put a 'halt' in MOCanvas>>drawOn: and you will see a long list of indirections that never ends (if your image is not yet frozen ;)). I just know that this is a FormCanvas that is passed. I also try to replace all references in pharo of FormCanvas by RomeBalloonCanvas, but this is still a FormCanvas that is passed to MOCanvas>>drawOn:. Therefore I didn't find any good solution to be able to switch between one kind of canvas to another kind. The MOCanvas is a morph, and I am not able to control its opening.
- What I have been able to do, is to modify the MOBrowser to not add
the MOCanvas in the browser, but an ImageMorph built throught the MOCanvas>>drawOn: method (setting myself a RomeBalloonCanvas as parameter). It works, but as an image morph, you will not be able to interact (like with the usual MOCanvas morph) . But you can already see how the visializations are drawn by basically replacing the formCanvas by a RomeBalloonCanvas. For simple visualization (like DistributionMap for example) , there is no big changes. So to try it, first, load last Version ofAthens: www.squeaksource.com/Athens Then the last version of Mondrian in: www.squeaksource.com/MondrianUsingRome And then open any visualization (in the same way that you usally do)
2010/6/16 Alexandre Bergel alexandre.bergel@inria.fr 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:
Hello,
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 ofForm).
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@inria.fr
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.
Yes, I will work on it. I have to identify where the slowness
comes from, from Mondrian or package blueprint.
Alexandre
Stef
On Jun 15, 2010, at 2:46 PM, Alexandre Bergel wrote:
I did not say that he did not say anything. I just said that
it 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.
Now we are in the situation in which multiple people noticed
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
On 15 Jun 2010, at 14:01, Stéphane Ducasse wrote:
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:
> One more thing. > > It can also be that when you have expensive traversals in
your blocks, you can easily get to quadratic algorithms.
> > For example, suppose you have something like this: > > view shape > height: [:each | (classes select: [:target | target
invokes: each]) size].
> view nodes: classes > > In this case, for each class, you would traverse all classes
again, so N^2.
> > That is why we need canonical examples first that expose
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 :)
> > Cheers, > Doru > > > On 15 Jun 2010, at 13:13, Tudor Girba wrote: > >> 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@iam.unibe.ch >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> >>>> -- >>>> www.tudorgirba.com >>>> >>>> "Presenting is storytelling." >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev@iam.unibe.ch >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev@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."
>> >> >> > > -- > www.tudorgirba.com > > "In a world where everything is moving ever faster, > one might have better chances to win by moving slower." > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev@iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Sometimes the best solution is not the best solution."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Every now and then stop and ask yourself if the war you're fighting is the right one."
if your visualization is not displayed throught a MOBrowser (this is the case for complexity ?), you will still use a FormCanvas provided by Morphic. As the API used is now the one of Rome, a FormCanvas will not not be able to understand any message, and nothing will be drawn. Does DistrbutionMap class>> example works ?
2010/6/21 Tudor Girba tudor.girba@gmail.com
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:
- I still do not know where the 'concrete canvas' from Morphic is passed
as argument to a MOCanvas. Try to put a 'halt' in MOCanvas>>drawOn: and you will see a long list of indirections that never ends (if your image is not yet frozen ;)). I just know that this is a FormCanvas that is passed. I also try to replace all references in pharo of FormCanvas by RomeBalloonCanvas, but this is still a FormCanvas that is passed to MOCanvas>>drawOn:. Therefore I didn't find any good solution to be able to switch between one kind of canvas to another kind. The MOCanvas is a morph, and I am not able to control its opening.
- What I have been able to do, is to modify the MOBrowser to not add the
MOCanvas in the browser, but an ImageMorph built throught the MOCanvas>>drawOn: method (setting myself a RomeBalloonCanvas as parameter). It works, but as an image morph, you will not be able to interact (like with the usual MOCanvas morph) . But you can already see how the visializations are drawn by basically replacing the formCanvas by a RomeBalloonCanvas. For simple visualization (like DistributionMap for example) , there is no big changes. So to try it, first, load last Version ofAthens: www.squeaksource.com/Athens Then the last version of Mondrian in: www.squeaksource.com/MondrianUsingRome And then open any visualization (in the same way that you usally do)
2010/6/16 Alexandre Bergel alexandre.bergel@inria.fr 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:
Hello,
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@inria.fr
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.
Yes, I will work on it. I have to identify where the slowness comes
from, from Mondrian or package blueprint.
Alexandre
Stef
On Jun 15, 2010, at 2:46 PM, Alexandre Bergel wrote:
I did not say that he did not say anything. I just said that it 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.
Now we are in the situation in which multiple people noticed
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
On 15 Jun 2010, at 14:01, Stéphane Ducasse wrote:
> 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: > >> One more thing. >> >> It can also be that when you have expensive traversals in your
blocks, you can easily get to quadratic algorithms.
>> >> For example, suppose you have something like this: >> >> view shape >> height: [:each | (classes select: [:target | target invokes:
each]) size].
>> view nodes: classes >> >> In this case, for each class, you would traverse all classes
again, so N^2.
>> >> That is why we need canonical examples first that expose 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 :)
>> >> Cheers, >> Doru >> >> >> On 15 Jun 2010, at 13:13, Tudor Girba wrote: >> >>> 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@iam.unibe.ch >>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>> >>>>> -- >>>>> www.tudorgirba.com >>>>> >>>>> "Presenting is storytelling." >>>>> >>>>> _______________________________________________ >>>>> Moose-dev mailing list >>>>> Moose-dev@iam.unibe.ch >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev@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."
>>> >>> >>> >> >> -- >> www.tudorgirba.com >> >> "In a world where everything is moving ever faster, >> one might have better chances to win by moving slower." >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev@iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > _______________________________________________ > Moose-dev mailing list > Moose-dev@iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Sometimes the best solution is not the best solution."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- 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@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@inria.fr
I did not say that he did not say anything. I just said that it 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.
Now we are in the situation in which multiple people noticed 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
On 15 Jun 2010, at 14:01, Stéphane Ducasse wrote:
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:
One more thing.
It can also be that when you have expensive traversals in your blocks,
you can easily get to quadratic algorithms.
For example, suppose you have something like this:
view shape height: [:each | (classes select: [:target | target invokes: each])
size].
view nodes: classes
In this case, for each class, you would traverse all classes again, so
N^2.
That is why we need canonical examples first that expose 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 :)
Cheers, Doru
On 15 Jun 2010, at 13:13, Tudor Girba wrote:
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@iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > > "Presenting is storytelling." > > _______________________________________________ > Moose-dev mailing list > Moose-dev@iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@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."
-- www.tudorgirba.com
"In a world where everything is moving ever faster, one might have better chances to win by moving slower."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Sometimes the best solution is not the best solution."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Hi Cyrille,
On 15 Jun 2010, at 16:40, Cyrille Delaunay wrote:
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 (?).
Yes, you understood correctly.
What seems to be sure, is that we can't specify easily a specific canvas to be used in mondrian
Why do you say that? It should be exactly as difficult as with any other Morph.
Could you please just tell us how you setup the canvas in your examples?
Cheers, Doru
2010/6/15 Alexandre Bergel alexandre.bergel@inria.fr
I did not say that he did not say anything. I just said that it 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.
Now we are in the situation in which multiple people noticed
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
On 15 Jun 2010, at 14:01, Stéphane Ducasse wrote:
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:
One more thing.
It can also be that when you have expensive traversals in your
blocks, you can easily get to quadratic algorithms.
For example, suppose you have something like this:
view shape height: [:each | (classes select: [:target | target invokes:
each]) size].
view nodes: classes
In this case, for each class, you would traverse all classes
again, so N^2.
That is why we need canonical examples first that expose 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 :)
Cheers, Doru
On 15 Jun 2010, at 13:13, Tudor Girba wrote:
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@iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > > "Presenting is storytelling." > > _______________________________________________ > Moose-dev mailing list > Moose-dev@iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@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."
-- www.tudorgirba.com
"In a world where everything is moving ever faster, one might have better chances to win by moving slower."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Sometimes the best solution is not the best solution."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Next time you see your life passing by, say 'hi' and get to know her."
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.
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?
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 (?).
Yes, you understood correctly.
What seems to be sure, is that we can't specify easily a specific canvas to be used in mondrian
Why do you say that? It should be exactly as difficult as with any other Morph.
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
Could you please just tell us how you setup the canvas in your examples?
have a look in the rome examples.
Cheers, Doru
2010/6/15 Alexandre Bergel alexandre.bergel@inria.fr
I did not say that he did not say anything. I just said that it 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.
Now we are in the situation in which multiple people noticed 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
On 15 Jun 2010, at 14:01, Stéphane Ducasse wrote:
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:
One more thing.
It can also be that when you have expensive traversals in your blocks, you can easily get to quadratic algorithms.
For example, suppose you have something like this:
view shape height: [:each | (classes select: [:target | target invokes: each]) size]. view nodes: classes
In this case, for each class, you would traverse all classes again, so N^2.
That is why we need canonical examples first that expose 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 :)
Cheers, Doru
On 15 Jun 2010, at 13:13, Tudor Girba wrote:
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@iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> www.tudorgirba.com >> >> "Presenting is storytelling." >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev@iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > _______________________________________________ > Moose-dev mailing list > Moose-dev@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."
-- www.tudorgirba.com
"In a world where everything is moving ever faster, one might have better chances to win by moving slower."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Sometimes the best solution is not the best solution."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Next time you see your life passing by, say 'hi' and get to know her."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Hi,
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.
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?
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 (?).
Yes, you understood correctly.
What seems to be sure, is that we can't specify easily a specific canvas to be used in mondrian
Why do you say that? It should be exactly as difficult as with any other Morph.
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
I know what Cyrille is saying.
Could you please just tell us how you setup the canvas in your examples?
have a look in the rome examples.
Ok, I can do that, but I just wanted to give the five minutes help I can afford right now. I will certainly take a look at a later time.
I the meantime, is it possible to describe in short what is the setup of the Rome examples?
Cheers Doru
Cheers, Doru
2010/6/15 Alexandre Bergel alexandre.bergel@inria.fr
I did not say that he did not say anything. I just said that it 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.
Now we are in the situation in which multiple people noticed 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
On 15 Jun 2010, at 14:01, Stéphane Ducasse wrote:
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:
One more thing.
It can also be that when you have expensive traversals in your blocks, you can easily get to quadratic algorithms.
For example, suppose you have something like this:
view shape height: [:each | (classes select: [:target | target invokes: each]) size]. view nodes: classes
In this case, for each class, you would traverse all classes again, so N^2.
That is why we need canonical examples first that expose 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 :)
Cheers, Doru
On 15 Jun 2010, at 13:13, Tudor Girba wrote:
> 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@iam.unibe.ch >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> -- >>> www.tudorgirba.com >>> >>> "Presenting is storytelling." >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev@iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev@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." > > >
-- www.tudorgirba.com
"In a world where everything is moving ever faster, one might have better chances to win by moving slower."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Sometimes the best solution is not the best solution."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Next time you see your life passing by, say 'hi' and get to know her."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Presenting is storytelling."
from Athens at squeaksource
demoMovingCarOn: aCanvas "[self demoMovingCarOn: RomePluginCanvas new] timeToRun" | c | c := aCanvas.
0 to: 3*360 by: 3 do: [:w| Display deferUpdates: true. c selectFill: Color white. c drawRectangle: (0@0 corner: 800@600). c preserveStateDuring: [ c translateBy: 100@100. c rotateBy: w around: 200@200. c translateBy: 20@180. c scaleBy: ((w * 2 / 180) cos) * 0.3 + 0.4. self drawCarOn: c. ]. c finish. Display deferUpdates: false. Display forceToScreen: (0@0 corner: 800@600). ]
demoRotateRomeOn: aCanvas "self demoRotateRomeOn: RomeCanvas new"
| c | c := aCanvas. c selectFill: Color white. c drawRectangle: (0@0 corner: 800@600). c font: (self fontFor: c family: 'Bitstream Vera Serif' style: 'Roman'). c fontSize: 1.
0 to: 360 by: 5 do: [:w| Display deferUpdates: true. c preserveStateDuring: [ c translateBy: 40@160. c scaleBy: (w * 0.7 max: 0.01). c rotateBy: w around: 1.5@0.75. c translateBy: 0.05@1. c selectPenWidth: 1/c transform scale y color: (Color blue alpha: (1 / 360 * w)). c selectFill: (Color r: 1 g: (1 / 360 * w) b: 0 alpha: (1 / 360 * w)). c drawString: 'Rome'. ]. c finish. Display deferUpdates: false. Display forceToScreen: (0@0 corner: 800@600). ]
then squeaksource went down.
Cyrille
using morph was a cheap way to avoid to rebuild everything but indeed may be writing in a real canvas and not a subclass of Morph could be a way to control it better.
orthogonally I do not know how we can say to a morph that it should be drawn on another canvas.
Setf
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@inria.fr
I did not say that he did not say anything. I just said that it 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.
Now we are in the situation in which multiple people noticed 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
On 15 Jun 2010, at 14:01, Stéphane Ducasse wrote:
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:
One more thing.
It can also be that when you have expensive traversals in your blocks, you can easily get to quadratic algorithms.
For example, suppose you have something like this:
view shape height: [:each | (classes select: [:target | target invokes: each]) size]. view nodes: classes
In this case, for each class, you would traverse all classes again, so N^2.
That is why we need canonical examples first that expose 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 :)
Cheers, Doru
On 15 Jun 2010, at 13:13, Tudor Girba wrote:
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@iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > > "Presenting is storytelling." > > _______________________________________________ > Moose-dev mailing list > Moose-dev@iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@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."
-- www.tudorgirba.com
"In a world where everything is moving ever faster, one might have better chances to win by moving slower."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Sometimes the best solution is not the best solution."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
so jannik can probably provide a case.
On Jun 15, 2010, at 2:24 PM, Tudor Girba wrote:
Hi Stef,
Who said that? :)
I did not say that he did not say anything. I just said that it 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.
Now we are in the situation in which multiple people noticed 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" :).
Doru
On 15 Jun 2010, at 14:01, Stéphane Ducasse wrote:
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:
One more thing.
It can also be that when you have expensive traversals in your blocks, you can easily get to quadratic algorithms.
For example, suppose you have something like this:
view shape height: [:each | (classes select: [:target | target invokes: each]) size]. view nodes: classes
In this case, for each class, you would traverse all classes again, so N^2.
That is why we need canonical examples first that expose 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 :)
Cheers, Doru
On 15 Jun 2010, at 13:13, Tudor Girba wrote:
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@iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Presenting is storytelling."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@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."
-- www.tudorgirba.com
"In a world where everything is moving ever faster, one might have better chances to win by moving slower."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Sometimes the best solution is not the best solution."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-
Alexandre Bergel -
Cyrille Delaunay -
Stéphane Ducasse -
Tudor Girba -
Veronica Isabel Uquillas Gomez