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 (?).
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(a)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(a)iam.unibe.ch
>>>>>>>>
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>>>
>>>>>>> --
>>>>>>>
www.tudorgirba.com
>>>>>>>
>>>>>>> "Presenting is storytelling."
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Moose-dev mailing list
>>>>>>> Moose-dev(a)iam.unibe.ch
>>>>>>>
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Moose-dev mailing list
>>>>>> Moose-dev(a)iam.unibe.ch
>>>>>>
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>
>>>>> --
>>>>>
www.tudorgirba.com
>>>>>
>>>>> "There are no old things, there are only old ways of looking
at them."
>>>
>>>
>>>
>>
>> --
>>
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(a)iam.unibe.ch
>>
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
>
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Sometimes the best solution is not the best solution."
_______________________________________________
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
_______________________________________________
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
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
"Next time you see your life passing by, say 'hi' and get to know her."