[Moose-dev] Re: [Mondrian] Where can we set the canvas to draw elements?

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(a)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: this Form that the drawing will be visible). class representing the display screen), but we can choose any other kind of Form. Form). integrate this Form to a Morph (?). one proposed by jannik a while ago comes from, from Mondrian or package blueprint. 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. multiple problems, there are some fixes, but there are still problems left. So, we have to dig deeper and we should do it more systematically by creating simpler cases that reproduce the problem. It's not an issue of "I told you so", it's an issue of "We need help to identify all problems" :). him that he did not want to help. your blocks, you can easily get to quadratic algorithms. invokes: each]) size]. again, so N^2. complex graphs. And those people that have a direct interest in getting Mondrian fast would be good to help in this direction, because it can get difficult to understand the particularities of each model :) for us: DSM, package blueprint, torch are all slow. found. Like not computing all the blocks all over the time. not clear what exactly generates the slowness. I believe the problem comes from the edges, but we have to take a more systematic look. 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. embedded in MOBrowser and MOEasel, which in their turn create a StandardWindow that holds the MOCanvas. adding the Athens canvas (which provides an abstraction over Cairo, Balloon and possibly others) behind Mondrian. canvas to use in Mondrian, but I didn't find. there is no references to FormCanvas in mondrian classes. in the class Form for example, so maybe such a method is use somewhere in the code. Mondrian ? looking at them." _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev