Smalltalk › Frameworks & Tools › Moose

Mondrian is slow (next step)

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

43 messages Options

123

jannik laval

Mondrian is slow (next step)

Hi all,

I localized the bug of Mondrian,

As Alex said, width and height are stored in cache, so a script like this work fine:

======

|view o |

view := MOViewRenderer new.

o := OrderedCollection new: 100.

1 to: 100 do:[:i | o add: i].

(view shape: (MORectangleShape new

width: [:e | (Delay forMilliseconds: 50) wait. 200];

height: 200;

withBorder;

borderColor: [:e | Color gray])).

view nodes: o.

view layout: (MOGridLayout new gapSize: 1).

view open

======

It is slow to generate, then it scroll well.

Now, if I do the same thing with a Delay in the block of borderColor:, the visualization is dead.

======

|view o |

view := MOViewRenderer new.

o := OrderedCollection new: 100.

1 to: 100 do:[:i | o add: i].

(view shape: (MORectangleShape new

width: [:e | 200];

height: 200;

withBorder;

borderColor: [:e | (Delay forMilliseconds: 50) wait. Color gray])).

view nodes: o.

view layout: (MOGridLayout new gapSize: 1).

view open

======

This is the bug we have in Blueprint, in eDSM and all the visualization we made.

I think shapes should keep these state and maybe react to announcement.

Cheers,

---

Jannik Laval

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Tudor Girba

Re: Mondrian is slow (next step)

Brilliant!

Indeed, this caching should happen for all properties and for all
shapes (both for nodes and for edges). I think that Alex stopped in
the middle because he did not know whether this caching had an effect
or not.

Alex, could you take a look at that?

The next question is that if the border color is called all the time,
what is the use of the bitmap cache?

Cheers,
Doru

On 16 Jun 2010, at 10:22, Laval Jannik wrote:

> Hi all,
>
> I localized the bug of Mondrian,
> As Alex said, width and height are stored in cache, so a script like
> this work fine:
>
> ======
> |view o |
> view := MOViewRenderer new.
> o := OrderedCollection new: 100.
> 1 to: 100 do:[:i | o add: i].
> (view shape: (MORectangleShape new
> width: [:e | (Delay forMilliseconds: 50) wait. 200];
> height: 200;
> withBorder;
> borderColor: [:e | Color gray])).
> view nodes: o.
> view layout: (MOGridLayout new gapSize: 1).
> view open
> ======
>
> It is slow to generate, then it scroll well.
>
> Now, if I do the same thing with a Delay in the block of
> borderColor:, the visualization is dead.
> ======
> |view o |
> view := MOViewRenderer new.
> o := OrderedCollection new: 100.
> 1 to: 100 do:[:i | o add: i].
> (view shape: (MORectangleShape new
> width: [:e | 200];
> height: 200;
> withBorder;
> borderColor: [:e | (Delay forMilliseconds: 50) wait. Color gray])).
> view nodes: o.
> view layout: (MOGridLayout new gapSize: 1).
> view open
> ======
>
> This is the bug we have in Blueprint, in eDSM and all the
> visualization we made.
> I think shapes should keep these state and maybe react to
> announcement.
>
> Cheers,
> ---
> Jannik Laval
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

--
www.tudorgirba.com

"When people care, great things can happen."

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Alexandre Bergel-4

Re: Mondrian is slow (next step)

> Indeed, this caching should happen for all properties and for all shapes (both for nodes and for edges). I think that Alex stopped in the middle because he did not know whether this caching had an effect or not.

I was wondering whether it would make sense to do this for all the metrics. Apparently yes, I then continued. All shape parameters should be cached.

> Alex, could you take a look at that?

Done. Mondrian-Alexandre_Bergel.470

> The next question is that if the border color is called all the time, what is the use of the bitmap cache?

The bitmap is for not having to display inner nodes. Recursion takes times.

>> ======
>> |view o |
>> view := MOViewRenderer new.
>> o := OrderedCollection new: 100.
>> 1 to: 100 do:[:i | o add: i].
>> (view shape: (MORectangleShape new
>> width: [:e | 200];
>> height: 200;
>> withBorder;
>> borderColor: [:e | (Delay forMilliseconds: 50) wait. Color gray])).
>> view nodes: o.
>> view layout: (MOGridLayout new gapSize: 1).
>> view open
>> ======

A better version could be
-=-=-=-=-=-=-=-=-=-=-=-=
|view o a |
a := {0}.
view := MOViewRenderer new.
o := OrderedCollection new: 100.
1 to: 100 do:[:i | o add: i].
(view shape: (MORectangleShape new
width: [:e | 200];
height: 200;
withBorder;
borderColor: [:e | a at: 1 put: (a first + 1). Color gray])).
view nodes: o.
view layout: (MOGridLayout new gapSize: 1).
view open.
a
-=-=-=-=-=-=-=-=-=-=-=-=

Just inspect the expression, and see if the array a changes over the time.

Is there any remaining problem left in Mondrian related to the speed issue?

Cheers,
Alexandre

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Tudor Girba

Re: Mondrian is slow (next step)

Hi Alex,

>> Indeed, this caching should happen for all properties and for all
>> shapes (both for nodes and for edges). I think that Alex stopped in
>> the middle because he did not know whether this caching had an
>> effect or not.
>
> I was wondering whether it would make sense to do this for all the
> metrics. Apparently yes, I then continued. All shape parameters
> should be cached.
>> Alex, could you take a look at that?
>
> Done. Mondrian-Alexandre_Bergel.470

Great. I checked a bit the implementation, and I would only suggest to
check for isCached in the attributeAt:ifAbsent: method, instead of in
every *For: methods.

>> The next question is that if the border color is called all the
>> time, what is the use of the bitmap cache?
>
> The bitmap is for not having to display inner nodes. Recursion takes
> times.

I know, but if you compute it once why do you still need to re-render?

Cheers,
Doru

>>> ======
>>> |view o |
>>> view := MOViewRenderer new.
>>> o := OrderedCollection new: 100.
>>> 1 to: 100 do:[:i | o add: i].
>>> (view shape: (MORectangleShape new
>>> width: [:e | 200];
>>> height: 200;
>>> withBorder;
>>> borderColor: [:e | (Delay forMilliseconds: 50) wait. Color gray])).
>>> view nodes: o.
>>> view layout: (MOGridLayout new gapSize: 1).
>>> view open
>>> ======
>
> A better version could be
> -=-=-=-=-=-=-=-=-=-=-=-=
> |view o a |
> a := {0}.
> view := MOViewRenderer new.
> o := OrderedCollection new: 100.
> 1 to: 100 do:[:i | o add: i].
> (view shape: (MORectangleShape new
> width: [:e | 200];
> height: 200;
> withBorder;
> borderColor: [:e | a at: 1 put: (a first + 1). Color gray])).
> view nodes: o.
> view layout: (MOGridLayout new gapSize: 1).
> view open.
> a
> -=-=-=-=-=-=-=-=-=-=-=-=
>
> Just inspect the expression, and see if the array a changes over the
> time.
>
> Is there any remaining problem left in Mondrian related to the speed
> issue?
>
> Cheers,
> Alexandre
>
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

--
www.tudorgirba.com

"Some battles are better lost than fought."

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Tudor Girba

Re: Mondrian is slow (next step)

I tested on a regular DSM with 259 namespaces and I can now properly
scroll once it gets displayed.

Jannik, Veronica, could you check in your cases?

Cheers,
Doru

On 17 Jun 2010, at 16:30, Tudor Girba wrote:

> Hi Alex,
>
>>> Indeed, this caching should happen for all properties and for all
>>> shapes (both for nodes and for edges). I think that Alex stopped
>>> in the middle because he did not know whether this caching had an
>>> effect or not.
>>
>> I was wondering whether it would make sense to do this for all the
>> metrics. Apparently yes, I then continued. All shape parameters
>> should be cached.
>>> Alex, could you take a look at that?
>>
>> Done. Mondrian-Alexandre_Bergel.470
>
> Great. I checked a bit the implementation, and I would only suggest
> to check for isCached in the attributeAt:ifAbsent: method, instead
> of in every *For: methods.
>
>>> The next question is that if the border color is called all the
>>> time, what is the use of the bitmap cache?
>>
>> The bitmap is for not having to display inner nodes. Recursion
>> takes times.
>
> I know, but if you compute it once why do you still need to re-render?
>
> Cheers,
> Doru
>
>
>
>>>> ======
>>>> |view o |
>>>> view := MOViewRenderer new.
>>>> o := OrderedCollection new: 100.
>>>> 1 to: 100 do:[:i | o add: i].
>>>> (view shape: (MORectangleShape new
>>>> width: [:e | 200];
>>>> height: 200;
>>>> withBorder;
>>>> borderColor: [:e | (Delay forMilliseconds: 50) wait. Color
>>>> gray])).
>>>> view nodes: o.
>>>> view layout: (MOGridLayout new gapSize: 1).
>>>> view open
>>>> ======
>>
>> A better version could be
>> -=-=-=-=-=-=-=-=-=-=-=-=
>> |view o a |
>> a := {0}.
>> view := MOViewRenderer new.
>> o := OrderedCollection new: 100.
>> 1 to: 100 do:[:i | o add: i].
>> (view shape: (MORectangleShape new
>> width: [:e | 200];
>> height: 200;
>> withBorder;
>> borderColor: [:e | a at: 1 put: (a first + 1). Color gray])).
>> view nodes: o.
>> view layout: (MOGridLayout new gapSize: 1).
>> view open.
>> a
>> -=-=-=-=-=-=-=-=-=-=-=-=
>>
>> Just inspect the expression, and see if the array a changes over
>> the time.
>>
>> Is there any remaining problem left in Mondrian related to the
>> speed issue?
>>
>> Cheers,
>> Alexandre
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> [hidden email]
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> --
> www.tudorgirba.com
>
> "Some battles are better lost than fought."
>
>
>

Alexandre Bergel-4

Re: Mondrian is slow (next step)

In reply to this post by Tudor Girba

> Great. I checked a bit the implementation, and I would only suggest to check for isCached in the attributeAt:ifAbsent: method, instead of in every *For: methods.

I instead introduced #cachedNamed:ifAbsentInitializeWith:
Not all attributes must be cached (e.g., I am doing some animation on the side)

For archive, I used this expression to check whether I missed some *For: methods.
-=-=-=-=-=-=-=-=-=-=-=-=
(((PackageInfo named: 'Mondrian') methods select: [:mr | mr selector asString endsWith: 'For:']) collect: [:mr | mr compiledMethod]) select: [:cm | (cm sendsSelector: #cachedNamed:ifAbsentInitializeWith:) not]
-=-=-=-=-=-=-=-=-=-=-=-=

I optimized what I could. I am not sure what to do with MOFormsShape although.

>>> The next question is that if the border color is called all the time, what is the use of the bitmap cache?
>>
>> The bitmap is for not having to display inner nodes. Recursion takes times.
>
> I know, but if you compute it once why do you still need to re-render?

Consider:

view node: 1 forIt: [view node: 2]].

Without the bitmap cache, you display two nodes (e.g., MOBoundedShape>>drawOn: is invoked twice).
It is called just once with the bitmap cache.

Alexandre

>
>
>
>>>> ======
>>>> |view o |
>>>> view := MOViewRenderer new.
>>>> o := OrderedCollection new: 100.
>>>> 1 to: 100 do:[:i | o add: i].
>>>> (view shape: (MORectangleShape new
>>>> width: [:e | 200];
>>>> height: 200;
>>>> withBorder;
>>>> borderColor: [:e | (Delay forMilliseconds: 50) wait. Color gray])).
>>>> view nodes: o.
>>>> view layout: (MOGridLayout new gapSize: 1).
>>>> view open
>>>> ======
>>
>> A better version could be
>> -=-=-=-=-=-=-=-=-=-=-=-=
>> |view o a |
>> a := {0}.
>> view := MOViewRenderer new.
>> o := OrderedCollection new: 100.
>> 1 to: 100 do:[:i | o add: i].
>> (view shape: (MORectangleShape new
>> width: [:e | 200];
>> height: 200;
>> withBorder;
>> borderColor: [:e | a at: 1 put: (a first + 1). Color gray])).
>> view nodes: o.
>> view layout: (MOGridLayout new gapSize: 1).
>> view open.
>> a
>> -=-=-=-=-=-=-=-=-=-=-=-=
>>
>> Just inspect the expression, and see if the array a changes over the time.
>>
>> Is there any remaining problem left in Mondrian related to the speed issue?
>>
>> Cheers,
>> Alexandre
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> [hidden email]
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> --
> www.tudorgirba.com
>
> "Some battles are better lost than fought."
>
>
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Alexandre Bergel-4

Re: Mondrian is slow (next step)

In reply to this post by Tudor Girba

Johan also saw an improvement in AspectsMap

This is cool to have discussed about this.

Alexandre

On 17 Jun 2010, at 11:47, Tudor Girba wrote:

> I tested on a regular DSM with 259 namespaces and I can now properly scroll once it gets displayed.
>
> Jannik, Veronica, could you check in your cases?
>
> Cheers,
> Doru
>
>
>
> On 17 Jun 2010, at 16:30, Tudor Girba wrote:
>
>> Hi Alex,
>>
>>>> Indeed, this caching should happen for all properties and for all shapes (both for nodes and for edges). I think that Alex stopped in the middle because he did not know whether this caching had an effect or not.
>>>
>>> I was wondering whether it would make sense to do this for all the metrics. Apparently yes, I then continued. All shape parameters should be cached.
>>>> Alex, could you take a look at that?
>>>
>>> Done. Mondrian-Alexandre_Bergel.470
>>
>> Great. I checked a bit the implementation, and I would only suggest to check for isCached in the attributeAt:ifAbsent: method, instead of in every *For: methods.
>>
>>>> The next question is that if the border color is called all the time, what is the use of the bitmap cache?
>>>
>>> The bitmap is for not having to display inner nodes. Recursion takes times.
>>
>> I know, but if you compute it once why do you still need to re-render?
>>
>> Cheers,
>> Doru
>>
>>
>>
>>>>> ======
>>>>> |view o |
>>>>> view := MOViewRenderer new.
>>>>> o := OrderedCollection new: 100.
>>>>> 1 to: 100 do:[:i | o add: i].
>>>>> (view shape: (MORectangleShape new
>>>>> width: [:e | 200];
>>>>> height: 200;
>>>>> withBorder;
>>>>> borderColor: [:e | (Delay forMilliseconds: 50) wait. Color gray])).
>>>>> view nodes: o.
>>>>> view layout: (MOGridLayout new gapSize: 1).
>>>>> view open
>>>>> ======
>>>
>>> A better version could be
>>> -=-=-=-=-=-=-=-=-=-=-=-=
>>> |view o a |
>>> a := {0}.
>>> view := MOViewRenderer new.
>>> o := OrderedCollection new: 100.
>>> 1 to: 100 do:[:i | o add: i].
>>> (view shape: (MORectangleShape new
>>> width: [:e | 200];
>>> height: 200;
>>> withBorder;
>>> borderColor: [:e | a at: 1 put: (a first + 1). Color gray])).
>>> view nodes: o.
>>> view layout: (MOGridLayout new gapSize: 1).
>>> view open.
>>> a
>>> -=-=-=-=-=-=-=-=-=-=-=-=
>>>
>>> Just inspect the expression, and see if the array a changes over the time.
>>>
>>> Is there any remaining problem left in Mondrian related to the speed issue?
>>>
>>> Cheers,
>>> Alexandre
>>>
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> [hidden email]
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>> --
>> www.tudorgirba.com
>>
>> "Some battles are better lost than fought."
>>
>>
>>
>
> --
> www.tudorgirba.com
>
> "Some battles are better lost than fought."
>
>
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

jfabry

Re: Mondrian is slow (next step)

Yes, AspectMapS ( :-P ) also sees the speedup. There is a problem with the zoom though, but Alex is already working on it :-)

On 17 Jun 2010, at 14:34, Alexandre Bergel wrote:

> Johan also saw an improvement in AspectsMap
>
> This is cool to have discussed about this.
>
> Alexandre
>
>
> On 17 Jun 2010, at 11:47, Tudor Girba wrote:
>
>> I tested on a regular DSM with 259 namespaces and I can now properly scroll once it gets displayed.
>>
>> Jannik, Veronica, could you check in your cases?
>>
>> Cheers,
>> Doru
>>
>

--
Johan Fabry
[hidden email] - http://dcc.uchile.cl/~jfabry
PLEIAD Lab - Computer Science Department (DCC) - University of Chile

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

jannik laval

Re: Mondrian is slow (next step)

In reply to this post by Tudor Girba

Hi,

Doru, do you do a DSM or a eDSM ?
With a eDSM, I do not see difference, I think there are some computation somewhere else.
Alex, do you cache all things ?

Thanks,
Jannik

On Jun 17, 2010, at 17:47 , Tudor Girba wrote:

---
Jannik Laval

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Veronica Isabel Uquillas Gomez

Re: Mondrian is slow (next step)

In reply to this post by Tudor Girba

Hi,

Can't test? where is MOLabelShape, why was it deleted??
I use it and now is gone!!! I even had a specialization of it for Torch...

Veronica

On 17 Jun 2010, at 17:47, Tudor Girba wrote:

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Tudor Girba

Re: Mondrian is slow (next step)

Hi Veronica,

As far as I know, the complete functionality of MOLabelShape is in
MORectangleShape. I guess that is why Alex removed it. I do not
particularly like that, but this is the situation now.

Could you subclass that one for the time being? Also, is the extension
not of interest for the general public? If yes, maybe it would make
sense to publish it in Mondrian directly :).

Cheers,
Doru

On 18 Jun 2010, at 09:43, Veronica Isabel Uquillas Gomez wrote:

> Hi,
>
> Can't test? where is MOLabelShape, why was it deleted??
> I use it and now is gone!!! I even had a specialization of it for
> Torch...
>
> Veronica
>
> On 17 Jun 2010, at 17:47, Tudor Girba wrote:
>
>> I tested on a regular DSM with 259 namespaces and I can now
>> properly scroll once it gets displayed.
>>
>> Jannik, Veronica, could you check in your cases?
>>
>> Cheers,
>> Doru
>>
>>
>>
>> On 17 Jun 2010, at 16:30, Tudor Girba wrote:
>>
>>> Hi Alex,
>>>
>>>>> Indeed, this caching should happen for all properties and for
>>>>> all shapes (both for nodes and for edges). I think that Alex
>>>>> stopped in the middle because he did not know whether this
>>>>> caching had an effect or not.
>>>>
>>>> I was wondering whether it would make sense to do this for all
>>>> the metrics. Apparently yes, I then continued. All shape
>>>> parameters should be cached.
>>>>> Alex, could you take a look at that?
>>>>
>>>> Done. Mondrian-Alexandre_Bergel.470
>>>
>>> Great. I checked a bit the implementation, and I would only
>>> suggest to check for isCached in the attributeAt:ifAbsent: method,
>>> instead of in every *For: methods.
>>>
>>>>> The next question is that if the border color is called all the
>>>>> time, what is the use of the bitmap cache?
>>>>
>>>> The bitmap is for not having to display inner nodes. Recursion
>>>> takes times.
>>>
>>> I know, but if you compute it once why do you still need to re-
>>> render?
>>>
>>> Cheers,
>>> Doru
>>>
>>>
>>>
>>>>>> ======
>>>>>> |view o |
>>>>>> view := MOViewRenderer new.
>>>>>> o := OrderedCollection new: 100.
>>>>>> 1 to: 100 do:[:i | o add: i].
>>>>>> (view shape: (MORectangleShape new
>>>>>> width: [:e | 200];
>>>>>> height: 200;
>>>>>> withBorder;
>>>>>> borderColor: [:e | (Delay forMilliseconds: 50) wait. Color
>>>>>> gray])).
>>>>>> view nodes: o.
>>>>>> view layout: (MOGridLayout new gapSize: 1).
>>>>>> view open
>>>>>> ======
>>>>
>>>> A better version could be
>>>> -=-=-=-=-=-=-=-=-=-=-=-=
>>>> |view o a |
>>>> a := {0}.
>>>> view := MOViewRenderer new.
>>>> o := OrderedCollection new: 100.
>>>> 1 to: 100 do:[:i | o add: i].
>>>> (view shape: (MORectangleShape new
>>>> width: [:e | 200];
>>>> height: 200;
>>>> withBorder;
>>>> borderColor: [:e | a at: 1 put: (a first + 1). Color gray])).
>>>> view nodes: o.
>>>> view layout: (MOGridLayout new gapSize: 1).
>>>> view open.
>>>> a
>>>> -=-=-=-=-=-=-=-=-=-=-=-=
>>>>
>>>> Just inspect the expression, and see if the array a changes over
>>>> the time.
>>>>
>>>> Is there any remaining problem left in Mondrian related to the
>>>> speed issue?
>>>>
>>>> Cheers,
>>>> Alexandre
>>>>
>>>>
>>>> _______________________________________________
>>>> Moose-dev mailing list
>>>> [hidden email]
>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>
>>> --
>>> www.tudorgirba.com
>>>
>>> "Some battles are better lost than fought."
>>>
>>>
>>>
>>
>> --
>> www.tudorgirba.com
>>
>> "Some battles are better lost than fought."
>>
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> [hidden email]
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> 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
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Tudor Girba

Re: Mondrian is slow (next step)

In reply to this post by jannik laval

Hi Jannik,

I tried a DSM. The eDSM gives me a subscript out of bounds error
somewhere deep in the contentOfCell: aView for: aCell with: aPackage
out: aBoolean method.

I applied this on the namespaces of JUnit. I attached the debug log.

Cheers,
Doru

On 18 Jun 2010, at 07:19, Laval Jannik wrote:

> Hi,
>
> Doru, do you do a DSM or a eDSM ?
> With a eDSM, I do not see difference, I think there are some
> computation somewhere else.
> Alex, do you cache all things ?
>
> Thanks,
> Jannik
>
> On Jun 17, 2010, at 17:47 , Tudor Girba wrote:
>
>> I tested on a regular DSM with 259 namespaces and I can now
>> properly scroll once it gets displayed.
>>
>> Jannik, Veronica, could you check in your cases?
>>
>> Cheers,
>> Doru
>>
>>
>>
>> On 17 Jun 2010, at 16:30, Tudor Girba wrote:
>>
>>> Hi Alex,
>>>
>>>>> Indeed, this caching should happen for all properties and for
>>>>> all shapes (both for nodes and for edges). I think that Alex
>>>>> stopped in the middle because he did not know whether this
>>>>> caching had an effect or not.
>>>>
>>>> I was wondering whether it would make sense to do this for all
>>>> the metrics. Apparently yes, I then continued. All shape
>>>> parameters should be cached.
>>>>> Alex, could you take a look at that?
>>>>
>>>> Done. Mondrian-Alexandre_Bergel.470
>>>
>>> Great. I checked a bit the implementation, and I would only
>>> suggest to check for isCached in the attributeAt:ifAbsent: method,
>>> instead of in every *For: methods.
>>>
>>>>> The next question is that if the border color is called all the
>>>>> time, what is the use of the bitmap cache?
>>>>
>>>> The bitmap is for not having to display inner nodes. Recursion
>>>> takes times.
>>>
>>> I know, but if you compute it once why do you still need to re-
>>> render?
>>>
>>> Cheers,
>>> Doru
>>>
>>>
>>>
>>>>>> ======
>>>>>> |view o |
>>>>>> view := MOViewRenderer new.
>>>>>> o := OrderedCollection new: 100.
>>>>>> 1 to: 100 do:[:i | o add: i].
>>>>>> (view shape: (MORectangleShape new
>>>>>> width: [:e | 200];
>>>>>> height: 200;
>>>>>> withBorder;
>>>>>> borderColor: [:e | (Delay forMilliseconds: 50) wait. Color
>>>>>> gray])).
>>>>>> view nodes: o.
>>>>>> view layout: (MOGridLayout new gapSize: 1).
>>>>>> view open
>>>>>> ======
>>>>
>>>> A better version could be
>>>> -=-=-=-=-=-=-=-=-=-=-=-=
>>>> |view o a |
>>>> a := {0}.
>>>> view := MOViewRenderer new.
>>>> o := OrderedCollection new: 100.
>>>> 1 to: 100 do:[:i | o add: i].
>>>> (view shape: (MORectangleShape new
>>>> width: [:e | 200];
>>>> height: 200;
>>>> withBorder;
>>>> borderColor: [:e | a at: 1 put: (a first + 1). Color gray])).
>>>> view nodes: o.
>>>> view layout: (MOGridLayout new gapSize: 1).
>>>> view open.
>>>> a
>>>> -=-=-=-=-=-=-=-=-=-=-=-=
>>>>
>>>> Just inspect the expression, and see if the array a changes over
>>>> the time.
>>>>
>>>> Is there any remaining problem left in Mondrian related to the
>>>> speed issue?
>>>>
>>>> Cheers,
>>>> Alexandre
>>>>
>>>>
>>>> _______________________________________________
>>>> Moose-dev mailing list
>>>> [hidden email]
>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>
>>> --
>>> www.tudorgirba.com
>>>
>>> "Some battles are better lost than fought."
>>>
>>>
>>>
>>
>> --
>> www.tudorgirba.com
>>
>> "Some battles are better lost than fought."
>>
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> [hidden email]
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> ---
> Jannik Laval
>
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

--
www.tudorgirba.com

"It's not how it is, it is how we see it."

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

debug.log (26K) Download Attachment

Veronica Isabel Uquillas Gomez

Re: Mondrian is slow (next step)

In reply to this post by Tudor Girba

Hi Doru,

In fact MOLabelShape shares the attributes with MOBoundedShape (rectangle does not do anything), but the drawing is not the same.

see the images, even having color black the text with the current version is like grey. That was one of the reasons for using labelShape and not rectangle at the beginning.
Plus the vertical padding works different, by default is 0 and you can not see the character p clearly, if I add a verticalPadding = 1 then i have more space that the one i need (see third image).

LabelShape controls that better with interlineSpace (not an accessor)... My extension changed that internal value, and i have an extra control for fonts.. In addition, Mondrian uses font cache (correct), but if you change the system fonts, that was not reflected on mondrian... I needed to validate that for Torch, another reason for my specialization...

If i make it publish, i will add in it the drawing behavior that was just removed.

regards,
Veronica

vs

On 18 Jun 2010, at 11:48, Tudor Girba wrote:

> Hi Veronica,
>
> As far as I know, the complete functionality of MOLabelShape is in MORectangleShape. I guess that is why Alex removed it. I do not particularly like that, but this is the situation now.
>
> Could you subclass that one for the time being? Also, is the extension not of interest for the general public? If yes, maybe it would make sense to publish it in Mondrian directly :).
>
> Cheers,
> Doru
>
>
> On 18 Jun 2010, at 09:43, Veronica Isabel Uquillas Gomez wrote:
>
>> Hi,
>>
>> Can't test? where is MOLabelShape, why was it deleted??
>> I use it and now is gone!!! I even had a specialization of it for Torch...
>>
>> Veronica
>>
>> On 17 Jun 2010, at 17:47, Tudor Girba wrote:
>>
>>> I tested on a regular DSM with 259 namespaces and I can now properly scroll once it gets displayed.
>>>
>>> Jannik, Veronica, could you check in your cases?
>>>
>>> Cheers,
>>> Doru
>>>
>>>
>>>
>>> On 17 Jun 2010, at 16:30, Tudor Girba wrote:
>>>
>>>> Hi Alex,
>>>>
>>>>>> Indeed, this caching should happen for all properties and for all shapes (both for nodes and for edges). I think that Alex stopped in the middle because he did not know whether this caching had an effect or not.
>>>>>
>>>>> I was wondering whether it would make sense to do this for all the metrics. Apparently yes, I then continued. All shape parameters should be cached.
>>>>>> Alex, could you take a look at that?
>>>>>
>>>>> Done. Mondrian-Alexandre_Bergel.470
>>>>
>>>> Great. I checked a bit the implementation, and I would only suggest to check for isCached in the attributeAt:ifAbsent: method, instead of in every *For: methods.
>>>>
>>>>>> The next question is that if the border color is called all the time, what is the use of the bitmap cache?
>>>>>
>>>>> The bitmap is for not having to display inner nodes. Recursion takes times.
>>>>
>>>> I know, but if you compute it once why do you still need to re-render?
>>>>
>>>> Cheers,
>>>> Doru
>>>>
>>>>
>>>>
>>>>>>> ======
>>>>>>> |view o |
>>>>>>> view := MOViewRenderer new.
>>>>>>> o := OrderedCollection new: 100.
>>>>>>> 1 to: 100 do:[:i | o add: i].
>>>>>>> (view shape: (MORectangleShape new
>>>>>>> width: [:e | 200];
>>>>>>> height: 200;
>>>>>>> withBorder;
>>>>>>> borderColor: [:e | (Delay forMilliseconds: 50) wait. Color gray])).
>>>>>>> view nodes: o.
>>>>>>> view layout: (MOGridLayout new gapSize: 1).
>>>>>>> view open
>>>>>>> ======
>>>>>
>>>>> A better version could be
>>>>> -=-=-=-=-=-=-=-=-=-=-=-=
>>>>> |view o a |
>>>>> a := {0}.
>>>>> view := MOViewRenderer new.
>>>>> o := OrderedCollection new: 100.
>>>>> 1 to: 100 do:[:i | o add: i].
>>>>> (view shape: (MORectangleShape new
>>>>> width: [:e | 200];
>>>>> height: 200;
>>>>> withBorder;
>>>>> borderColor: [:e | a at: 1 put: (a first + 1). Color gray])).
>>>>> view nodes: o.
>>>>> view layout: (MOGridLayout new gapSize: 1).
>>>>> view open.
>>>>> a
>>>>> -=-=-=-=-=-=-=-=-=-=-=-=
>>>>>
>>>>> Just inspect the expression, and see if the array a changes over the time.
>>>>>
>>>>> Is there any remaining problem left in Mondrian related to the speed issue?
>>>>>
>>>>> Cheers,
>>>>> Alexandre
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Moose-dev mailing list
>>>>> [hidden email]
>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>
>>>> --
>>>> www.tudorgirba.com
>>>>
>>>> "Some battles are better lost than fought."
>>>>
>>>>
>>>>
>>>
>>> --
>>> www.tudorgirba.com
>>>
>>> "Some battles are better lost than fought."
>>>
>>>
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> [hidden email]
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> [hidden email]
>> 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
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

labelShape-extension.png (12K) Download Attachment

labelShape-now.png (11K) Download Attachment

labelShape-now+padding.png (11K) Download Attachment

Alexandre Bergel-4

Re: Mondrian is slow (next step)

In reply to this post by jannik laval

> Alex, do you cache all things ?

All the parameters in a shape that could be cached are now cached (e.g., width: height: fillColor: borderColor: ...)

Cheers,
Alexandre

>
> Thanks,
> Jannik
>
> On Jun 17, 2010, at 17:47 , Tudor Girba wrote:
>
>> I tested on a regular DSM with 259 namespaces and I can now properly scroll once it gets displayed.
>>
>> Jannik, Veronica, could you check in your cases?
>>
>> Cheers,
>> Doru
>>
>>
>>
>> On 17 Jun 2010, at 16:30, Tudor Girba wrote:
>>
>>> Hi Alex,
>>>
>>>>> Indeed, this caching should happen for all properties and for all shapes (both for nodes and for edges). I think that Alex stopped in the middle because he did not know whether this caching had an effect or not.
>>>>
>>>> I was wondering whether it would make sense to do this for all the metrics. Apparently yes, I then continued. All shape parameters should be cached.
>>>>> Alex, could you take a look at that?
>>>>
>>>> Done. Mondrian-Alexandre_Bergel.470
>>>
>>> Great. I checked a bit the implementation, and I would only suggest to check for isCached in the attributeAt:ifAbsent: method, instead of in every *For: methods.
>>>
>>>>> The next question is that if the border color is called all the time, what is the use of the bitmap cache?
>>>>
>>>> The bitmap is for not having to display inner nodes. Recursion takes times.
>>>
>>> I know, but if you compute it once why do you still need to re-render?
>>>
>>> Cheers,
>>> Doru
>>>
>>>
>>>
>>>>>> ======
>>>>>> |view o |
>>>>>> view := MOViewRenderer new.
>>>>>> o := OrderedCollection new: 100.
>>>>>> 1 to: 100 do:[:i | o add: i].
>>>>>> (view shape: (MORectangleShape new
>>>>>> width: [:e | 200];
>>>>>> height: 200;
>>>>>> withBorder;
>>>>>> borderColor: [:e | (Delay forMilliseconds: 50) wait. Color gray])).
>>>>>> view nodes: o.
>>>>>> view layout: (MOGridLayout new gapSize: 1).
>>>>>> view open
>>>>>> ======
>>>>
>>>> A better version could be
>>>> -=-=-=-=-=-=-=-=-=-=-=-=
>>>> |view o a |
>>>> a := {0}.
>>>> view := MOViewRenderer new.
>>>> o := OrderedCollection new: 100.
>>>> 1 to: 100 do:[:i | o add: i].
>>>> (view shape: (MORectangleShape new
>>>> width: [:e | 200];
>>>> height: 200;
>>>> withBorder;
>>>> borderColor: [:e | a at: 1 put: (a first + 1). Color gray])).
>>>> view nodes: o.
>>>> view layout: (MOGridLayout new gapSize: 1).
>>>> view open.
>>>> a
>>>> -=-=-=-=-=-=-=-=-=-=-=-=
>>>>
>>>> Just inspect the expression, and see if the array a changes over the time.
>>>>
>>>> Is there any remaining problem left in Mondrian related to the speed issue?
>>>>
>>>> Cheers,
>>>> Alexandre
>>>>
>>>>
>>>> _______________________________________________
>>>> Moose-dev mailing list
>>>> [hidden email]
>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>
>>> --
>>> www.tudorgirba.com
>>>
>>> "Some battles are better lost than fought."
>>>
>>>
>>>
>>
>> --
>> www.tudorgirba.com
>>
>> "Some battles are better lost than fought."
>>
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> [hidden email]
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> ---
> Jannik Laval
>
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Alexandre Bergel-4

Re: Mondrian is slow (next step)

In reply to this post by Veronica Isabel Uquillas Gomez

Yes, I removed it.
Veronica, I can reintroduce it, but could you try to adapt your code with MORectangleShape ?
MORectangleShape new withoutBorder; text: [:v | ... ] closely emulates MOLabelShape.

Let me know if this is a problem.

Cheers,
Alexandre

On 18 Jun 2010, at 03:43, Veronica Isabel Uquillas Gomez wrote:

> Hi,
>
> Can't test? where is MOLabelShape, why was it deleted??
> I use it and now is gone!!! I even had a specialization of it for Torch...
>
> Veronica
>
> On 17 Jun 2010, at 17:47, Tudor Girba wrote:
>
>> I tested on a regular DSM with 259 namespaces and I can now properly scroll once it gets displayed.
>>
>> Jannik, Veronica, could you check in your cases?
>>
>> Cheers,
>> Doru
>>
>>
>>
>> On 17 Jun 2010, at 16:30, Tudor Girba wrote:
>>
>>> Hi Alex,
>>>
>>>>> Indeed, this caching should happen for all properties and for all shapes (both for nodes and for edges). I think that Alex stopped in the middle because he did not know whether this caching had an effect or not.
>>>>
>>>> I was wondering whether it would make sense to do this for all the metrics. Apparently yes, I then continued. All shape parameters should be cached.
>>>>> Alex, could you take a look at that?
>>>>
>>>> Done. Mondrian-Alexandre_Bergel.470
>>>
>>> Great. I checked a bit the implementation, and I would only suggest to check for isCached in the attributeAt:ifAbsent: method, instead of in every *For: methods.
>>>
>>>>> The next question is that if the border color is called all the time, what is the use of the bitmap cache?
>>>>
>>>> The bitmap is for not having to display inner nodes. Recursion takes times.
>>>
>>> I know, but if you compute it once why do you still need to re-render?
>>>
>>> Cheers,
>>> Doru
>>>
>>>
>>>
>>>>>> ======
>>>>>> |view o |
>>>>>> view := MOViewRenderer new.
>>>>>> o := OrderedCollection new: 100.
>>>>>> 1 to: 100 do:[:i | o add: i].
>>>>>> (view shape: (MORectangleShape new
>>>>>> width: [:e | 200];
>>>>>> height: 200;
>>>>>> withBorder;
>>>>>> borderColor: [:e | (Delay forMilliseconds: 50) wait. Color gray])).
>>>>>> view nodes: o.
>>>>>> view layout: (MOGridLayout new gapSize: 1).
>>>>>> view open
>>>>>> ======
>>>>
>>>> A better version could be
>>>> -=-=-=-=-=-=-=-=-=-=-=-=
>>>> |view o a |
>>>> a := {0}.
>>>> view := MOViewRenderer new.
>>>> o := OrderedCollection new: 100.
>>>> 1 to: 100 do:[:i | o add: i].
>>>> (view shape: (MORectangleShape new
>>>> width: [:e | 200];
>>>> height: 200;
>>>> withBorder;
>>>> borderColor: [:e | a at: 1 put: (a first + 1). Color gray])).
>>>> view nodes: o.
>>>> view layout: (MOGridLayout new gapSize: 1).
>>>> view open.
>>>> a
>>>> -=-=-=-=-=-=-=-=-=-=-=-=
>>>>
>>>> Just inspect the expression, and see if the array a changes over the time.
>>>>
>>>> Is there any remaining problem left in Mondrian related to the speed issue?
>>>>
>>>> Cheers,
>>>> Alexandre
>>>>
>>>>
>>>> _______________________________________________
>>>> Moose-dev mailing list
>>>> [hidden email]
>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>
>>> --
>>> www.tudorgirba.com
>>>
>>> "Some battles are better lost than fought."
>>>
>>>
>>>
>>
>> --
>> www.tudorgirba.com
>>
>> "Some battles are better lost than fought."
>>
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> [hidden email]
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Alexandre Bergel-4

Re: Mondrian is slow (next step)

In reply to this post by Tudor Girba

> As far as I know, the complete functionality of MOLabelShape is in MORectangleShape. I guess that is why Alex removed it. I do not particularly like that, but this is the situation now.

Indeed. There is a severe duplication of functionalities in MORectangleShape and MOLabelShape.
Sorry Veronica to add you more work.

> Could you subclass that one for the time being? Also, is the extension not of interest for the general public? If yes, maybe it would make sense to
> publish it in Mondrian directly :).

Good question.

Alexandre

>
> Cheers,
> Doru
>
>
> On 18 Jun 2010, at 09:43, Veronica Isabel Uquillas Gomez wrote:
>
>> Hi,
>>
>> Can't test? where is MOLabelShape, why was it deleted??
>> I use it and now is gone!!! I even had a specialization of it for Torch...
>>
>> Veronica
>>
>> On 17 Jun 2010, at 17:47, Tudor Girba wrote:
>>
>>> I tested on a regular DSM with 259 namespaces and I can now properly scroll once it gets displayed.
>>>
>>> Jannik, Veronica, could you check in your cases?
>>>
>>> Cheers,
>>> Doru
>>>
>>>
>>>
>>> On 17 Jun 2010, at 16:30, Tudor Girba wrote:
>>>
>>>> Hi Alex,
>>>>
>>>>>> Indeed, this caching should happen for all properties and for all shapes (both for nodes and for edges). I think that Alex stopped in the middle because he did not know whether this caching had an effect or not.
>>>>>
>>>>> I was wondering whether it would make sense to do this for all the metrics. Apparently yes, I then continued. All shape parameters should be cached.
>>>>>> Alex, could you take a look at that?
>>>>>
>>>>> Done. Mondrian-Alexandre_Bergel.470
>>>>
>>>> Great. I checked a bit the implementation, and I would only suggest to check for isCached in the attributeAt:ifAbsent: method, instead of in every *For: methods.
>>>>
>>>>>> The next question is that if the border color is called all the time, what is the use of the bitmap cache?
>>>>>
>>>>> The bitmap is for not having to display inner nodes. Recursion takes times.
>>>>
>>>> I know, but if you compute it once why do you still need to re-render?
>>>>
>>>> Cheers,
>>>> Doru
>>>>
>>>>
>>>>
>>>>>>> ======
>>>>>>> |view o |
>>>>>>> view := MOViewRenderer new.
>>>>>>> o := OrderedCollection new: 100.
>>>>>>> 1 to: 100 do:[:i | o add: i].
>>>>>>> (view shape: (MORectangleShape new
>>>>>>> width: [:e | 200];
>>>>>>> height: 200;
>>>>>>> withBorder;
>>>>>>> borderColor: [:e | (Delay forMilliseconds: 50) wait. Color gray])).
>>>>>>> view nodes: o.
>>>>>>> view layout: (MOGridLayout new gapSize: 1).
>>>>>>> view open
>>>>>>> ======
>>>>>
>>>>> A better version could be
>>>>> -=-=-=-=-=-=-=-=-=-=-=-=
>>>>> |view o a |
>>>>> a := {0}.
>>>>> view := MOViewRenderer new.
>>>>> o := OrderedCollection new: 100.
>>>>> 1 to: 100 do:[:i | o add: i].
>>>>> (view shape: (MORectangleShape new
>>>>> width: [:e | 200];
>>>>> height: 200;
>>>>> withBorder;
>>>>> borderColor: [:e | a at: 1 put: (a first + 1). Color gray])).
>>>>> view nodes: o.
>>>>> view layout: (MOGridLayout new gapSize: 1).
>>>>> view open.
>>>>> a
>>>>> -=-=-=-=-=-=-=-=-=-=-=-=
>>>>>
>>>>> Just inspect the expression, and see if the array a changes over the time.
>>>>>
>>>>> Is there any remaining problem left in Mondrian related to the speed issue?
>>>>>
>>>>> Cheers,
>>>>> Alexandre
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Moose-dev mailing list
>>>>> [hidden email]
>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>
>>>> --
>>>> www.tudorgirba.com
>>>>
>>>> "Some battles are better lost than fought."
>>>>
>>>>
>>>>
>>>
>>> --
>>> www.tudorgirba.com
>>>
>>> "Some battles are better lost than fought."
>>>
>>>
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> [hidden email]
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> [hidden email]
>> 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
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Stéphane Ducasse

Re: Mondrian is slow (next step)

In reply to this post by jfabry

excellent
we were not aware that the properties were not cached else we would have produce a delay long time ago

On Jun 17, 2010, at 8:50 PM, Johan Fabry wrote:

>
> Yes, AspectMapS ( :-P ) also sees the speedup. There is a problem with the zoom though, but Alex is already working on it :-)
>
> On 17 Jun 2010, at 14:34, Alexandre Bergel wrote:
>
>> Johan also saw an improvement in AspectsMap
>>
>> This is cool to have discussed about this.
>>
>> Alexandre
>>
>>
>> On 17 Jun 2010, at 11:47, Tudor Girba wrote:
>>
>>> I tested on a regular DSM with 259 namespaces and I can now properly scroll once it gets displayed.
>>>
>>> Jannik, Veronica, could you check in your cases?
>>>
>>> Cheers,
>>> Doru
>>>
>>
>
> --
> Johan Fabry
> [hidden email] - http://dcc.uchile.cl/~jfabry
> PLEIAD Lab - Computer Science Department (DCC) - University of Chile
>
>
>
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Veronica Isabel Uquillas Gomez

Re: Mondrian is slow (next step)

In reply to this post by Alexandre Bergel-4

I did, and i also sent a mail explaining the differences with images...

On 18 Jun 2010, at 14:51, Alexandre Bergel wrote:

> Yes, I removed it.
> Veronica, I can reintroduce it, but could you try to adapt your code with MORectangleShape ?
> MORectangleShape new withoutBorder; text: [:v | ... ] closely emulates MOLabelShape.
>
> Let me know if this is a problem.
>
> Cheers,
> Alexandre
>
>
> On 18 Jun 2010, at 03:43, Veronica Isabel Uquillas Gomez wrote:
>
>> Hi,
>>
>> Can't test? where is MOLabelShape, why was it deleted??
>> I use it and now is gone!!! I even had a specialization of it for Torch...
>>
>> Veronica
>>
>> On 17 Jun 2010, at 17:47, Tudor Girba wrote:
>>
>>> I tested on a regular DSM with 259 namespaces and I can now properly scroll once it gets displayed.
>>>
>>> Jannik, Veronica, could you check in your cases?
>>>
>>> Cheers,
>>> Doru
>>>
>>>
>>>
>>> On 17 Jun 2010, at 16:30, Tudor Girba wrote:
>>>
>>>> Hi Alex,
>>>>
>>>>>> Indeed, this caching should happen for all properties and for all shapes (both for nodes and for edges). I think that Alex stopped in the middle because he did not know whether this caching had an effect or not.
>>>>>
>>>>> I was wondering whether it would make sense to do this for all the metrics. Apparently yes, I then continued. All shape parameters should be cached.
>>>>>> Alex, could you take a look at that?
>>>>>
>>>>> Done. Mondrian-Alexandre_Bergel.470
>>>>
>>>> Great. I checked a bit the implementation, and I would only suggest to check for isCached in the attributeAt:ifAbsent: method, instead of in every *For: methods.
>>>>
>>>>>> The next question is that if the border color is called all the time, what is the use of the bitmap cache?
>>>>>
>>>>> The bitmap is for not having to display inner nodes. Recursion takes times.
>>>>
>>>> I know, but if you compute it once why do you still need to re-render?
>>>>
>>>> Cheers,
>>>> Doru
>>>>
>>>>
>>>>
>>>>>>> ======
>>>>>>> |view o |
>>>>>>> view := MOViewRenderer new.
>>>>>>> o := OrderedCollection new: 100.
>>>>>>> 1 to: 100 do:[:i | o add: i].
>>>>>>> (view shape: (MORectangleShape new
>>>>>>> width: [:e | 200];
>>>>>>> height: 200;
>>>>>>> withBorder;
>>>>>>> borderColor: [:e | (Delay forMilliseconds: 50) wait. Color gray])).
>>>>>>> view nodes: o.
>>>>>>> view layout: (MOGridLayout new gapSize: 1).
>>>>>>> view open
>>>>>>> ======
>>>>>
>>>>> A better version could be
>>>>> -=-=-=-=-=-=-=-=-=-=-=-=
>>>>> |view o a |
>>>>> a := {0}.
>>>>> view := MOViewRenderer new.
>>>>> o := OrderedCollection new: 100.
>>>>> 1 to: 100 do:[:i | o add: i].
>>>>> (view shape: (MORectangleShape new
>>>>> width: [:e | 200];
>>>>> height: 200;
>>>>> withBorder;
>>>>> borderColor: [:e | a at: 1 put: (a first + 1). Color gray])).
>>>>> view nodes: o.
>>>>> view layout: (MOGridLayout new gapSize: 1).
>>>>> view open.
>>>>> a
>>>>> -=-=-=-=-=-=-=-=-=-=-=-=
>>>>>
>>>>> Just inspect the expression, and see if the array a changes over the time.
>>>>>
>>>>> Is there any remaining problem left in Mondrian related to the speed issue?
>>>>>
>>>>> Cheers,
>>>>> Alexandre
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Moose-dev mailing list
>>>>> [hidden email]
>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>
>>>> --
>>>> www.tudorgirba.com
>>>>
>>>> "Some battles are better lost than fought."
>>>>
>>>>
>>>>
>>>
>>> --
>>> www.tudorgirba.com
>>>
>>> "Some battles are better lost than fought."
>>>
>>>
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> [hidden email]
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> [hidden email]
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Veronica Isabel Uquillas Gomez

Re: Mondrian is slow (next step)

In reply to this post by Alexandre Bergel-4

On 18 Jun 2010, at 14:53, Alexandre Bergel wrote:

>> As far as I know, the complete functionality of MOLabelShape is in MORectangleShape. I guess that is why Alex removed it. I do not particularly like that, but this is the situation now.
>
> Indeed. There is a severe duplication of functionalities in MORectangleShape and MOLabelShape.
> Sorry Veronica to add you more work.

i agree with removing duplications, but removing a class that may be used for other applications without notifying, no...
the version in which it was deleted has not even a comment for that...

>
>> Could you subclass that one for the time being? Also, is the extension not of interest for the general public? If yes, maybe it would make sense to
>> publish it in Mondrian directly :).
>
> Good question.
>
> Alexandre
>
>
>>
>> Cheers,
>> Doru
>>
>>
>> On 18 Jun 2010, at 09:43, Veronica Isabel Uquillas Gomez wrote:
>>
>>> Hi,
>>>
>>> Can't test? where is MOLabelShape, why was it deleted??
>>> I use it and now is gone!!! I even had a specialization of it for Torch...
>>>
>>> Veronica
>>>
>>> On 17 Jun 2010, at 17:47, Tudor Girba wrote:
>>>
>>>> I tested on a regular DSM with 259 namespaces and I can now properly scroll once it gets displayed.
>>>>
>>>> Jannik, Veronica, could you check in your cases?
>>>>
>>>> Cheers,
>>>> Doru
>>>>
>>>>
>>>>
>>>> On 17 Jun 2010, at 16:30, Tudor Girba wrote:
>>>>
>>>>> Hi Alex,
>>>>>
>>>>>>> Indeed, this caching should happen for all properties and for all shapes (both for nodes and for edges). I think that Alex stopped in the middle because he did not know whether this caching had an effect or not.
>>>>>>
>>>>>> I was wondering whether it would make sense to do this for all the metrics. Apparently yes, I then continued. All shape parameters should be cached.
>>>>>>> Alex, could you take a look at that?
>>>>>>
>>>>>> Done. Mondrian-Alexandre_Bergel.470
>>>>>
>>>>> Great. I checked a bit the implementation, and I would only suggest to check for isCached in the attributeAt:ifAbsent: method, instead of in every *For: methods.
>>>>>
>>>>>>> The next question is that if the border color is called all the time, what is the use of the bitmap cache?
>>>>>>
>>>>>> The bitmap is for not having to display inner nodes. Recursion takes times.
>>>>>
>>>>> I know, but if you compute it once why do you still need to re-render?
>>>>>
>>>>> Cheers,
>>>>> Doru
>>>>>
>>>>>
>>>>>
>>>>>>>> ======
>>>>>>>> |view o |
>>>>>>>> view := MOViewRenderer new.
>>>>>>>> o := OrderedCollection new: 100.
>>>>>>>> 1 to: 100 do:[:i | o add: i].
>>>>>>>> (view shape: (MORectangleShape new
>>>>>>>> width: [:e | 200];
>>>>>>>> height: 200;
>>>>>>>> withBorder;
>>>>>>>> borderColor: [:e | (Delay forMilliseconds: 50) wait. Color gray])).
>>>>>>>> view nodes: o.
>>>>>>>> view layout: (MOGridLayout new gapSize: 1).
>>>>>>>> view open
>>>>>>>> ======
>>>>>>
>>>>>> A better version could be
>>>>>> -=-=-=-=-=-=-=-=-=-=-=-=
>>>>>> |view o a |
>>>>>> a := {0}.
>>>>>> view := MOViewRenderer new.
>>>>>> o := OrderedCollection new: 100.
>>>>>> 1 to: 100 do:[:i | o add: i].
>>>>>> (view shape: (MORectangleShape new
>>>>>> width: [:e | 200];
>>>>>> height: 200;
>>>>>> withBorder;
>>>>>> borderColor: [:e | a at: 1 put: (a first + 1). Color gray])).
>>>>>> view nodes: o.
>>>>>> view layout: (MOGridLayout new gapSize: 1).
>>>>>> view open.
>>>>>> a
>>>>>> -=-=-=-=-=-=-=-=-=-=-=-=
>>>>>>
>>>>>> Just inspect the expression, and see if the array a changes over the time.
>>>>>>
>>>>>> Is there any remaining problem left in Mondrian related to the speed issue?
>>>>>>
>>>>>> Cheers,
>>>>>> Alexandre
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Moose-dev mailing list
>>>>>> [hidden email]
>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>
>>>>> --
>>>>> www.tudorgirba.com
>>>>>
>>>>> "Some battles are better lost than fought."
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> www.tudorgirba.com
>>>>
>>>> "Some battles are better lost than fought."
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Moose-dev mailing list
>>>> [hidden email]
>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> [hidden email]
>>> 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
>> [hidden email]
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Alexandre Bergel-4

Re: Mondrian is slow (next step)

In reply to this post by Veronica Isabel Uquillas Gomez

> In fact MOLabelShape shares the attributes with MOBoundedShape (rectangle does not do anything), but the drawing is not the same.

MORectangleShape does not do anything. Some of the functionalities of MOBoundedShape will be moved down to MORectangleShape.
Also, MOBoundedShape may be merged with MOFilledShape. I have to think about that. So far, it does not make sense to have
MONodeShape
MOFilledShape
MOBoundedShape
MOCurveShape
MODiamondShape
...
MORectangleShape
>
> see the images, even having color black the text with the current version is like grey. That was one of the reasons for using labelShape and not rectangle at the beginning.

I cannot reproduce this difference of color. I attached what I have in my image. The code that displays the string is rigorously the same.

I tried this:

with MOLabelShape, the font is darker than with MORectangleShape.

I found the reason. MORectangleShape always displays a whiteBackground before displaying the text. For some reason, the text appears gray in that situation. I added MOBoundedShape>>withoutBackGroup. It solves the problem apparently.

Does this solve your problem?

> Plus the vertical padding works different, by default is 0 and you can not see the character p clearly, if I add a verticalPadding = 1 then i have more space that the one i need (see third image).

I cannot reproduce this. I inserted some times ago textPadding.

Does it solve your issue?

> LabelShape controls that better with interlineSpace (not an accessor)... My extension changed that internal value, and i have an extra control for fonts..

Which control?

> In addition, Mondrian uses font cache (correct), but if you change the system fonts, that was not reflected on mondrian... I needed to validate that for Torch, another reason for my specialization...

I guess it should.

> If i make it publish, i will add in it the drawing behavior that was just removed.

I do not understand.
Please, let me know how after this discussion if you are happy with MORectangleShape.

Cheers,
Alexandre

>
> regards,
> Veronica
>
> <labelShape-extension.png> vs<labelShape-now.png>
>
> <labelShape-now+padding.png>
>
>
>
>
> On 18 Jun 2010, at 11:48, Tudor Girba wrote:
>
>> Hi Veronica,
>>
>> As far as I know, the complete functionality of MOLabelShape is in MORectangleShape. I guess that is why Alex removed it. I do not particularly like that, but this is the situation now.
>>
>> Could you subclass that one for the time being? Also, is the extension not of interest for the general public? If yes, maybe it would make sense to publish it in Mondrian directly :).
>>
>> Cheers,
>> Doru
>>
>>
>> On 18 Jun 2010, at 09:43, Veronica Isabel Uquillas Gomez wrote:
>>
>>> Hi,
>>>
>>> Can't test? where is MOLabelShape, why was it deleted??
>>> I use it and now is gone!!! I even had a specialization of it for Torch...
>>>
>>> Veronica
>>>
>>> On 17 Jun 2010, at 17:47, Tudor Girba wrote:
>>>
>>>> I tested on a regular DSM with 259 namespaces and I can now properly scroll once it gets displayed.
>>>>
>>>> Jannik, Veronica, could you check in your cases?
>>>>
>>>> Cheers,
>>>> Doru
>>>>
>>>>
>>>>
>>>> On 17 Jun 2010, at 16:30, Tudor Girba wrote:
>>>>
>>>>> Hi Alex,
>>>>>
>>>>>>> Indeed, this caching should happen for all properties and for all shapes (both for nodes and for edges). I think that Alex stopped in the middle because he did not know whether this caching had an effect or not.
>>>>>>
>>>>>> I was wondering whether it would make sense to do this for all the metrics. Apparently yes, I then continued. All shape parameters should be cached.
>>>>>>> Alex, could you take a look at that?
>>>>>>
>>>>>> Done. Mondrian-Alexandre_Bergel.470
>>>>>
>>>>> Great. I checked a bit the implementation, and I would only suggest to check for isCached in the attributeAt:ifAbsent: method, instead of in every *For: methods.
>>>>>
>>>>>>> The next question is that if the border color is called all the time, what is the use of the bitmap cache?
>>>>>>
>>>>>> The bitmap is for not having to display inner nodes. Recursion takes times.
>>>>>
>>>>> I know, but if you compute it once why do you still need to re-render?
>>>>>
>>>>> Cheers,
>>>>> Doru
>>>>>
>>>>>
>>>>>
>>>>>>>> ======
>>>>>>>> |view o |
>>>>>>>> view := MOViewRenderer new.
>>>>>>>> o := OrderedCollection new: 100.
>>>>>>>> 1 to: 100 do:[:i | o add: i].
>>>>>>>> (view shape: (MORectangleShape new
>>>>>>>> width: [:e | 200];
>>>>>>>> height: 200;
>>>>>>>> withBorder;
>>>>>>>> borderColor: [:e | (Delay forMilliseconds: 50) wait. Color gray])).
>>>>>>>> view nodes: o.
>>>>>>>> view layout: (MOGridLayout new gapSize: 1).
>>>>>>>> view open
>>>>>>>> ======
>>>>>>
>>>>>> A better version could be
>>>>>> -=-=-=-=-=-=-=-=-=-=-=-=
>>>>>> |view o a |
>>>>>> a := {0}.
>>>>>> view := MOViewRenderer new.
>>>>>> o := OrderedCollection new: 100.
>>>>>> 1 to: 100 do:[:i | o add: i].
>>>>>> (view shape: (MORectangleShape new
>>>>>> width: [:e | 200];
>>>>>> height: 200;
>>>>>> withBorder;
>>>>>> borderColor: [:e | a at: 1 put: (a first + 1). Color gray])).
>>>>>> view nodes: o.
>>>>>> view layout: (MOGridLayout new gapSize: 1).
>>>>>> view open.
>>>>>> a
>>>>>> -=-=-=-=-=-=-=-=-=-=-=-=
>>>>>>
>>>>>> Just inspect the expression, and see if the array a changes over the time.
>>>>>>
>>>>>> Is there any remaining problem left in Mondrian related to the speed issue?
>>>>>>
>>>>>> Cheers,
>>>>>> Alexandre
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Moose-dev mailing list
>>>>>> [hidden email]
>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>
>>>>> --
>>>>> www.tudorgirba.com
>>>>>
>>>>> "Some battles are better lost than fought."
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> www.tudorgirba.com
>>>>
>>>> "Some battles are better lost than fought."
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Moose-dev mailing list
>>>> [hidden email]
>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> [hidden email]
>>> 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
>> [hidden email]
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Screen shot 2010-06-18 at 09.09.04.png (20K) Download Attachment

Screen shot 2010-06-18 at 09.12.36.png (21K) Download Attachment

Screen shot 2010-06-18 at 09.25.44.png (37K) Download Attachment

Screen shot 2010-06-18 at 09.32.35.png (39K) Download Attachment

Screen shot 2010-06-18 at 09.27.48.png (38K) Download Attachment

123