Mondrian Health report and new version of Mondrian

> Dear Mondrian friends,
>
> A new cache mechanism has been implemented and some part have been simplified. The goal was to make Package blueprint fast without reducing the speed up for other visualization. The goal has been reached. On my machine, Package Blueprint is snappy (as soon as it got displayed and you do not select anything).
>
> The health report shown below is sensibly the same than the one sent few days ago. However, the new benchmark ("Benchmark many small nodes") is the one that reproduce a situation found in package blueprint. It was costly before this version.
>
> I would like you to try the last version of Mondrian. I tested it against class blueprint and it behaves as it should. However, you may notice some differences. Was the rendering and scrolling faster for you? Are you happy with this new version?
>
>
> Report produced on 2010-07-16T09:13:19+02:00
> System version Pharo-1.1-11400-rc2 of 12 June 2010 update 11400
> Benchmark ManyNode (simple rendering of nodes) :
>  100 nodes => 7 ms
>  200 nodes => 12 ms
>  300 nodes => 18 ms
>  400 nodes => 23 ms
>  500 nodes => 30 ms
>  600 nodes => 35 ms
>  700 nodes => 41 ms
>  800 nodes => 46 ms
>  900 nodes => 52 ms
>  1000 nodes => 58 ms
>  1600 nodes => 93 ms
>  3200 nodes => 186 ms
>  6400 nodes => 373 ms
> Benchmark ManyEdges (simple rendering of edges) :
>  10 edges => 3 ms
>  20 edges => 9 ms
>  30 edges => 21 ms
>  40 edges => 38 ms
>  50 edges => 65 ms
>  60 edges => 102 ms
>  70 edges => 153 ms
>  80 edges => 223 ms
>  90 edges => 310 ms
>  100 edges => 409 ms
>  200 edges => 5844 ms
>  300 edges => 37619 ms
> Benchmark ManyInnerNodes :
>  5 nodes => 170 ms
>  10 nodes => 3012 ms
>  15 nodes => 11589 ms
> Benchmark Displaying ManyInnerNodes :
>  5 nodes => 152 ms
>  10 nodes => 1526 ms
>  15 nodes => 11186 ms
> Benchmark Displaying ManyInnerNodesAndEdges :
>  1 nodes => 9 ms
>  2 nodes => 239 ms
>  3 nodes => 3278 ms
>  4 nodes => 30492 ms
> Benchmark Displaying elementAt :
>  100 nodes => 3 ms
>  500 nodes => 5 ms
>  1000 nodes => 9 ms
>  1500 nodes => 11 ms
>  2000 nodes => 14 ms
>  2500 nodes => 16 ms
> Benchmark many small nodes :
>  2000 nodes => 2368 ms
>
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

> Dear Mondrian friends,
>
> A new cache mechanism has been implemented and some part have been simplified. The goal was to make Package blueprint fast without reducing the speed up for other visualization. The goal has been reached. On my machine, Package Blueprint is snappy (as soon as it got displayed and you do not select anything).
>
> The health report shown below is sensibly the same than the one sent few days ago. However, the new benchmark ("Benchmark many small nodes") is the one that reproduce a situation found in package blueprint. It was costly before this version.
>
> I would like you to try the last version of Mondrian. I tested it against class blueprint and it behaves as it should. However, you may notice some differences. Was the rendering and scrolling faster for you? Are you happy with this new version?
>
>
> Report produced on 2010-07-16T09:13:19+02:00
> System version Pharo-1.1-11400-rc2 of 12 June 2010 update 11400
> Benchmark ManyNode (simple rendering of nodes) :
>  100 nodes => 7 ms
>  200 nodes => 12 ms
>  300 nodes => 18 ms
>  400 nodes => 23 ms
>  500 nodes => 30 ms
>  600 nodes => 35 ms
>  700 nodes => 41 ms
>  800 nodes => 46 ms
>  900 nodes => 52 ms
>  1000 nodes => 58 ms
>  1600 nodes => 93 ms
>  3200 nodes => 186 ms
>  6400 nodes => 373 ms
> Benchmark ManyEdges (simple rendering of edges) :
>  10 edges => 3 ms
>  20 edges => 9 ms
>  30 edges => 21 ms
>  40 edges => 38 ms
>  50 edges => 65 ms
>  60 edges => 102 ms
>  70 edges => 153 ms
>  80 edges => 223 ms
>  90 edges => 310 ms
>  100 edges => 409 ms
>  200 edges => 5844 ms
>  300 edges => 37619 ms
> Benchmark ManyInnerNodes :
>  5 nodes => 170 ms
>  10 nodes => 3012 ms
>  15 nodes => 11589 ms
> Benchmark Displaying ManyInnerNodes :
>  5 nodes => 152 ms
>  10 nodes => 1526 ms
>  15 nodes => 11186 ms
> Benchmark Displaying ManyInnerNodesAndEdges :
>  1 nodes => 9 ms
>  2 nodes => 239 ms
>  3 nodes => 3278 ms
>  4 nodes => 30492 ms
> Benchmark Displaying elementAt :
>  100 nodes => 3 ms
>  500 nodes => 5 ms
>  1000 nodes => 9 ms
>  1500 nodes => 11 ms
>  2000 nodes => 14 ms
>  2500 nodes => 16 ms
> Benchmark many small nodes :
>  2000 nodes => 2368 ms
>
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

>
> On Jul 16, 2010, at 9:31 AM, Alexandre Bergel wrote:
>
>> Dear Mondrian friends,
>>
>> A new cache mechanism has been implemented and some part have been simplified. The goal was to make Package blueprint fast without reducing the speed up for other visualization. The goal has been reached. On my machine, Package Blueprint is snappy (as soon as it got displayed and you do not select anything).
>>
>> The health report shown below is sensibly the same than the one sent few days ago. However, the new benchmark ("Benchmark many small nodes") is the one that reproduce a situation found in package blueprint. It was costly before this version.
>>
>> I would like you to try the last version of Mondrian. I tested it against class blueprint and it behaves as it should. However, you may notice some differences. Was the rendering and scrolling faster for you? Are you happy with this new version?
>>
>>
>> Report produced on 2010-07-16T09:13:19+02:00
>> System version Pharo-1.1-11400-rc2 of 12 June 2010 update 11400
>> Benchmark ManyNode (simple rendering of nodes) :
>> 100 nodes => 7 ms
>> 200 nodes => 12 ms
>> 300 nodes => 18 ms
>> 400 nodes => 23 ms
>> 500 nodes => 30 ms
>> 600 nodes => 35 ms
>> 700 nodes => 41 ms
>> 800 nodes => 46 ms
>> 900 nodes => 52 ms
>> 1000 nodes => 58 ms
>> 1600 nodes => 93 ms
>> 3200 nodes => 186 ms
>> 6400 nodes => 373 ms
>> Benchmark ManyEdges (simple rendering of edges) :
>> 10 edges => 3 ms
>> 20 edges => 9 ms
>> 30 edges => 21 ms
>> 40 edges => 38 ms
>> 50 edges => 65 ms
>> 60 edges => 102 ms
>> 70 edges => 153 ms
>> 80 edges => 223 ms
>> 90 edges => 310 ms
>> 100 edges => 409 ms
>> 200 edges => 5844 ms
>> 300 edges => 37619 ms
>> Benchmark ManyInnerNodes :
>> 5 nodes => 170 ms
>> 10 nodes => 3012 ms
>> 15 nodes => 11589 ms
>> Benchmark Displaying ManyInnerNodes :
>> 5 nodes => 152 ms
>> 10 nodes => 1526 ms
>> 15 nodes => 11186 ms
>> Benchmark Displaying ManyInnerNodesAndEdges :
>> 1 nodes => 9 ms
>> 2 nodes => 239 ms
>> 3 nodes => 3278 ms
>> 4 nodes => 30492 ms
>> Benchmark Displaying elementAt :
>> 100 nodes => 3 ms
>> 500 nodes => 5 ms
>> 1000 nodes => 9 ms
>> 1500 nodes => 11 ms
>> 2000 nodes => 14 ms
>> 2500 nodes => 16 ms
>> Benchmark many small nodes :
>> 2000 nodes => 2368 ms
>>
>> --
>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>> Alexandre Bergel  http://www.bergel.eu
>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> 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

> Hi Alex,
>
> The new version creates serious problems for system complexity: everything appears double. See the attachment.
>
> Also, in the blueprint, the bounds are again cropping the top and the left side of the visualization.
>
> I tested both with the Cog and with regular VM.
>
> Cheers,
> Doru
>
> <Picture 1.png>
>
>
>
> On 16 Jul 2010, at 10:27, Alexandre Bergel wrote:
>
>>> thanks alex
>>> we are really stressing mondrian with our crazy ideas.
>>
>> Package blueprint was indeed interesting.
>> Thousands of small nodes contained in a large node, big enough to not be cached using the former system. Large nodes are now bitmap cached even if they are partially displayed. It looks obvious, but converging to this solution took time...
>>
>> Thanks for all your bug report.
>>
>> Cheers,
>> Alexandre
>>
>>>
>>> On Jul 16, 2010, at 9:31 AM, Alexandre Bergel wrote:
>>>
>>>> Dear Mondrian friends,
>>>>
>>>> A new cache mechanism has been implemented and some part have been simplified. The goal was to make Package blueprint fast without reducing the speed up for other visualization. The goal has been reached. On my machine, Package Blueprint is snappy (as soon as it got displayed and you do not select anything).
>>>>
>>>> The health report shown below is sensibly the same than the one sent few days ago. However, the new benchmark ("Benchmark many small nodes") is the one that reproduce a situation found in package blueprint. It was costly before this version.
>>>>
>>>> I would like you to try the last version of Mondrian. I tested it against class blueprint and it behaves as it should. However, you may notice some differences. Was the rendering and scrolling faster for you? Are you happy with this new version?
>>>>
>>>>
>>>> Report produced on 2010-07-16T09:13:19+02:00
>>>> System version Pharo-1.1-11400-rc2 of 12 June 2010 update 11400
>>>> Benchmark ManyNode (simple rendering of nodes) :
>>>> 100 nodes => 7 ms
>>>> 200 nodes => 12 ms
>>>> 300 nodes => 18 ms
>>>> 400 nodes => 23 ms
>>>> 500 nodes => 30 ms
>>>> 600 nodes => 35 ms
>>>> 700 nodes => 41 ms
>>>> 800 nodes => 46 ms
>>>> 900 nodes => 52 ms
>>>> 1000 nodes => 58 ms
>>>> 1600 nodes => 93 ms
>>>> 3200 nodes => 186 ms
>>>> 6400 nodes => 373 ms
>>>> Benchmark ManyEdges (simple rendering of edges) :
>>>> 10 edges => 3 ms
>>>> 20 edges => 9 ms
>>>> 30 edges => 21 ms
>>>> 40 edges => 38 ms
>>>> 50 edges => 65 ms
>>>> 60 edges => 102 ms
>>>> 70 edges => 153 ms
>>>> 80 edges => 223 ms
>>>> 90 edges => 310 ms
>>>> 100 edges => 409 ms
>>>> 200 edges => 5844 ms
>>>> 300 edges => 37619 ms
>>>> Benchmark ManyInnerNodes :
>>>> 5 nodes => 170 ms
>>>> 10 nodes => 3012 ms
>>>> 15 nodes => 11589 ms
>>>> Benchmark Displaying ManyInnerNodes :
>>>> 5 nodes => 152 ms
>>>> 10 nodes => 1526 ms
>>>> 15 nodes => 11186 ms
>>>> Benchmark Displaying ManyInnerNodesAndEdges :
>>>> 1 nodes => 9 ms
>>>> 2 nodes => 239 ms
>>>> 3 nodes => 3278 ms
>>>> 4 nodes => 30492 ms
>>>> Benchmark Displaying elementAt :
>>>> 100 nodes => 3 ms
>>>> 500 nodes => 5 ms
>>>> 1000 nodes => 9 ms
>>>> 1500 nodes => 11 ms
>>>> 2000 nodes => 14 ms
>>>> 2500 nodes => 16 ms
>>>> Benchmark many small nodes :
>>>> 2000 nodes => 2368 ms
>>>>
>>>> --
>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>>> Alexandre Bergel  http://www.bergel.eu
>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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  http://www.bergel.eu
>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> [hidden email]
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> --
> www.tudorgirba.com
>
> "What is more important: To be happy, or to make happy?"
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

> Strange. I cannot reproduce the issue.
> It works properly with me.
>
> Jannik, can you try to open a system complexity please?
>
> Cheers,
> Alexandre
>
>
> On 16 Jul 2010, at 10:56, Tudor Girba wrote:
>
>> Hi Alex,
>>
>> The new version creates serious problems for system complexity: everything appears double. See the attachment.
>>
>> Also, in the blueprint, the bounds are again cropping the top and the left side of the visualization.
>>
>> I tested both with the Cog and with regular VM.
>>
>> Cheers,
>> Doru
>>
>> <Picture 1.png>
>>
>>
>>
>> On 16 Jul 2010, at 10:27, Alexandre Bergel wrote:
>>
>>>> thanks alex
>>>> we are really stressing mondrian with our crazy ideas.
>>>
>>> Package blueprint was indeed interesting.
>>> Thousands of small nodes contained in a large node, big enough to not be cached using the former system. Large nodes are now bitmap cached even if they are partially displayed. It looks obvious, but converging to this solution took time...
>>>
>>> Thanks for all your bug report.
>>>
>>> Cheers,
>>> Alexandre
>>>
>>>>
>>>> On Jul 16, 2010, at 9:31 AM, Alexandre Bergel wrote:
>>>>
>>>>> Dear Mondrian friends,
>>>>>
>>>>> A new cache mechanism has been implemented and some part have been simplified. The goal was to make Package blueprint fast without reducing the speed up for other visualization. The goal has been reached. On my machine, Package Blueprint is snappy (as soon as it got displayed and you do not select anything).
>>>>>
>>>>> The health report shown below is sensibly the same than the one sent few days ago. However, the new benchmark ("Benchmark many small nodes") is the one that reproduce a situation found in package blueprint. It was costly before this version.
>>>>>
>>>>> I would like you to try the last version of Mondrian. I tested it against class blueprint and it behaves as it should. However, you may notice some differences. Was the rendering and scrolling faster for you? Are you happy with this new version?
>>>>>
>>>>>
>>>>> Report produced on 2010-07-16T09:13:19+02:00
>>>>> System version Pharo-1.1-11400-rc2 of 12 June 2010 update 11400
>>>>> Benchmark ManyNode (simple rendering of nodes) :
>>>>> 100 nodes => 7 ms
>>>>> 200 nodes => 12 ms
>>>>> 300 nodes => 18 ms
>>>>> 400 nodes => 23 ms
>>>>> 500 nodes => 30 ms
>>>>> 600 nodes => 35 ms
>>>>> 700 nodes => 41 ms
>>>>> 800 nodes => 46 ms
>>>>> 900 nodes => 52 ms
>>>>> 1000 nodes => 58 ms
>>>>> 1600 nodes => 93 ms
>>>>> 3200 nodes => 186 ms
>>>>> 6400 nodes => 373 ms
>>>>> Benchmark ManyEdges (simple rendering of edges) :
>>>>> 10 edges => 3 ms
>>>>> 20 edges => 9 ms
>>>>> 30 edges => 21 ms
>>>>> 40 edges => 38 ms
>>>>> 50 edges => 65 ms
>>>>> 60 edges => 102 ms
>>>>> 70 edges => 153 ms
>>>>> 80 edges => 223 ms
>>>>> 90 edges => 310 ms
>>>>> 100 edges => 409 ms
>>>>> 200 edges => 5844 ms
>>>>> 300 edges => 37619 ms
>>>>> Benchmark ManyInnerNodes :
>>>>> 5 nodes => 170 ms
>>>>> 10 nodes => 3012 ms
>>>>> 15 nodes => 11589 ms
>>>>> Benchmark Displaying ManyInnerNodes :
>>>>> 5 nodes => 152 ms
>>>>> 10 nodes => 1526 ms
>>>>> 15 nodes => 11186 ms
>>>>> Benchmark Displaying ManyInnerNodesAndEdges :
>>>>> 1 nodes => 9 ms
>>>>> 2 nodes => 239 ms
>>>>> 3 nodes => 3278 ms
>>>>> 4 nodes => 30492 ms
>>>>> Benchmark Displaying elementAt :
>>>>> 100 nodes => 3 ms
>>>>> 500 nodes => 5 ms
>>>>> 1000 nodes => 9 ms
>>>>> 1500 nodes => 11 ms
>>>>> 2000 nodes => 14 ms
>>>>> 2500 nodes => 16 ms
>>>>> Benchmark many small nodes :
>>>>> 2000 nodes => 2368 ms
>>>>>
>>>>> --
>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>>>> Alexandre Bergel  http://www.bergel.eu
>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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  http://www.bergel.eu
>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> [hidden email]
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>> --
>> www.tudorgirba.com
>>
>> "What is more important: To be happy, or to make happy?"
>>
>> _______________________________________________
>> Moose-dev mailing list
>> [hidden email]
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

> Yes, I reproduce it.
> In a small system complexity, the problem does not appear (Network)
> In Seaside, a big one (1100 classes), I have the same bug as Doru.
>
> Jannik
>
> On Jul 16, 2010, at 11:17 , Alexandre Bergel wrote:
>
>> Strange. I cannot reproduce the issue.
>> It works properly with me.
>>
>> Jannik, can you try to open a system complexity please?
>>
>> Cheers,
>> Alexandre
>>
>>
>> On 16 Jul 2010, at 10:56, Tudor Girba wrote:
>>
>>> Hi Alex,
>>>
>>> The new version creates serious problems for system complexity: everything appears double. See the attachment.
>>>
>>> Also, in the blueprint, the bounds are again cropping the top and the left side of the visualization.
>>>
>>> I tested both with the Cog and with regular VM.
>>>
>>> Cheers,
>>> Doru
>>>
>>> <Picture 1.png>
>>>
>>>
>>>
>>> On 16 Jul 2010, at 10:27, Alexandre Bergel wrote:
>>>
>>>>> thanks alex
>>>>> we are really stressing mondrian with our crazy ideas.
>>>>
>>>> Package blueprint was indeed interesting.
>>>> Thousands of small nodes contained in a large node, big enough to not be cached using the former system. Large nodes are now bitmap cached even if they are partially displayed. It looks obvious, but converging to this solution took time...
>>>>
>>>> Thanks for all your bug report.
>>>>
>>>> Cheers,
>>>> Alexandre
>>>>
>>>>>
>>>>> On Jul 16, 2010, at 9:31 AM, Alexandre Bergel wrote:
>>>>>
>>>>>> Dear Mondrian friends,
>>>>>>
>>>>>> A new cache mechanism has been implemented and some part have been simplified. The goal was to make Package blueprint fast without reducing the speed up for other visualization. The goal has been reached. On my machine, Package Blueprint is snappy (as soon as it got displayed and you do not select anything).
>>>>>>
>>>>>> The health report shown below is sensibly the same than the one sent few days ago. However, the new benchmark ("Benchmark many small nodes") is the one that reproduce a situation found in package blueprint. It was costly before this version.
>>>>>>
>>>>>> I would like you to try the last version of Mondrian. I tested it against class blueprint and it behaves as it should. However, you may notice some differences. Was the rendering and scrolling faster for you? Are you happy with this new version?
>>>>>>
>>>>>>
>>>>>> Report produced on 2010-07-16T09:13:19+02:00
>>>>>> System version Pharo-1.1-11400-rc2 of 12 June 2010 update 11400
>>>>>> Benchmark ManyNode (simple rendering of nodes) :
>>>>>> 100 nodes => 7 ms
>>>>>> 200 nodes => 12 ms
>>>>>> 300 nodes => 18 ms
>>>>>> 400 nodes => 23 ms
>>>>>> 500 nodes => 30 ms
>>>>>> 600 nodes => 35 ms
>>>>>> 700 nodes => 41 ms
>>>>>> 800 nodes => 46 ms
>>>>>> 900 nodes => 52 ms
>>>>>> 1000 nodes => 58 ms
>>>>>> 1600 nodes => 93 ms
>>>>>> 3200 nodes => 186 ms
>>>>>> 6400 nodes => 373 ms
>>>>>> Benchmark ManyEdges (simple rendering of edges) :
>>>>>> 10 edges => 3 ms
>>>>>> 20 edges => 9 ms
>>>>>> 30 edges => 21 ms
>>>>>> 40 edges => 38 ms
>>>>>> 50 edges => 65 ms
>>>>>> 60 edges => 102 ms
>>>>>> 70 edges => 153 ms
>>>>>> 80 edges => 223 ms
>>>>>> 90 edges => 310 ms
>>>>>> 100 edges => 409 ms
>>>>>> 200 edges => 5844 ms
>>>>>> 300 edges => 37619 ms
>>>>>> Benchmark ManyInnerNodes :
>>>>>> 5 nodes => 170 ms
>>>>>> 10 nodes => 3012 ms
>>>>>> 15 nodes => 11589 ms
>>>>>> Benchmark Displaying ManyInnerNodes :
>>>>>> 5 nodes => 152 ms
>>>>>> 10 nodes => 1526 ms
>>>>>> 15 nodes => 11186 ms
>>>>>> Benchmark Displaying ManyInnerNodesAndEdges :
>>>>>> 1 nodes => 9 ms
>>>>>> 2 nodes => 239 ms
>>>>>> 3 nodes => 3278 ms
>>>>>> 4 nodes => 30492 ms
>>>>>> Benchmark Displaying elementAt :
>>>>>> 100 nodes => 3 ms
>>>>>> 500 nodes => 5 ms
>>>>>> 1000 nodes => 9 ms
>>>>>> 1500 nodes => 11 ms
>>>>>> 2000 nodes => 14 ms
>>>>>> 2500 nodes => 16 ms
>>>>>> Benchmark many small nodes :
>>>>>> 2000 nodes => 2368 ms
>>>>>>
>>>>>> --
>>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>>>>> Alexandre Bergel  http://www.bergel.eu
>>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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  http://www.bergel.eu
>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Moose-dev mailing list
>>>> [hidden email]
>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>
>>> --
>>> www.tudorgirba.com
>>>
>>> "What is more important: To be happy, or to make happy?"
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> [hidden email]
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>> --
>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>> Alexandre Bergel  http://www.bergel.eu
>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> 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

> I tried a system complexity on the Moose model (all famix classes) and it works well...
> I come to see you Jannik.
>
> Alexandre
>
>
> On 16 Jul 2010, at 11:22, Laval Jannik wrote:
>
>> Yes, I reproduce it.
>> In a small system complexity, the problem does not appear (Network)
>> In Seaside, a big one (1100 classes), I have the same bug as Doru.
>>
>> Jannik
>>
>> On Jul 16, 2010, at 11:17 , Alexandre Bergel wrote:
>>
>>> Strange. I cannot reproduce the issue.
>>> It works properly with me.
>>>
>>> Jannik, can you try to open a system complexity please?
>>>
>>> Cheers,
>>> Alexandre
>>>
>>>
>>> On 16 Jul 2010, at 10:56, Tudor Girba wrote:
>>>
>>>> Hi Alex,
>>>>
>>>> The new version creates serious problems for system complexity: everything appears double. See the attachment.
>>>>
>>>> Also, in the blueprint, the bounds are again cropping the top and the left side of the visualization.
>>>>
>>>> I tested both with the Cog and with regular VM.
>>>>
>>>> Cheers,
>>>> Doru
>>>>
>>>> <Picture 1.png>
>>>>
>>>>
>>>>
>>>> On 16 Jul 2010, at 10:27, Alexandre Bergel wrote:
>>>>
>>>>>> thanks alex
>>>>>> we are really stressing mondrian with our crazy ideas.
>>>>>
>>>>> Package blueprint was indeed interesting.
>>>>> Thousands of small nodes contained in a large node, big enough to not be cached using the former system. Large nodes are now bitmap cached even if they are partially displayed. It looks obvious, but converging to this solution took time...
>>>>>
>>>>> Thanks for all your bug report.
>>>>>
>>>>> Cheers,
>>>>> Alexandre
>>>>>
>>>>>>
>>>>>> On Jul 16, 2010, at 9:31 AM, Alexandre Bergel wrote:
>>>>>>
>>>>>>> Dear Mondrian friends,
>>>>>>>
>>>>>>> A new cache mechanism has been implemented and some part have been simplified. The goal was to make Package blueprint fast without reducing the speed up for other visualization. The goal has been reached. On my machine, Package Blueprint is snappy (as soon as it got displayed and you do not select anything).
>>>>>>>
>>>>>>> The health report shown below is sensibly the same than the one sent few days ago. However, the new benchmark ("Benchmark many small nodes") is the one that reproduce a situation found in package blueprint. It was costly before this version.
>>>>>>>
>>>>>>> I would like you to try the last version of Mondrian. I tested it against class blueprint and it behaves as it should. However, you may notice some differences. Was the rendering and scrolling faster for you? Are you happy with this new version?
>>>>>>>
>>>>>>>
>>>>>>> Report produced on 2010-07-16T09:13:19+02:00
>>>>>>> System version Pharo-1.1-11400-rc2 of 12 June 2010 update 11400
>>>>>>> Benchmark ManyNode (simple rendering of nodes) :
>>>>>>> 100 nodes => 7 ms
>>>>>>> 200 nodes => 12 ms
>>>>>>> 300 nodes => 18 ms
>>>>>>> 400 nodes => 23 ms
>>>>>>> 500 nodes => 30 ms
>>>>>>> 600 nodes => 35 ms
>>>>>>> 700 nodes => 41 ms
>>>>>>> 800 nodes => 46 ms
>>>>>>> 900 nodes => 52 ms
>>>>>>> 1000 nodes => 58 ms
>>>>>>> 1600 nodes => 93 ms
>>>>>>> 3200 nodes => 186 ms
>>>>>>> 6400 nodes => 373 ms
>>>>>>> Benchmark ManyEdges (simple rendering of edges) :
>>>>>>> 10 edges => 3 ms
>>>>>>> 20 edges => 9 ms
>>>>>>> 30 edges => 21 ms
>>>>>>> 40 edges => 38 ms
>>>>>>> 50 edges => 65 ms
>>>>>>> 60 edges => 102 ms
>>>>>>> 70 edges => 153 ms
>>>>>>> 80 edges => 223 ms
>>>>>>> 90 edges => 310 ms
>>>>>>> 100 edges => 409 ms
>>>>>>> 200 edges => 5844 ms
>>>>>>> 300 edges => 37619 ms
>>>>>>> Benchmark ManyInnerNodes :
>>>>>>> 5 nodes => 170 ms
>>>>>>> 10 nodes => 3012 ms
>>>>>>> 15 nodes => 11589 ms
>>>>>>> Benchmark Displaying ManyInnerNodes :
>>>>>>> 5 nodes => 152 ms
>>>>>>> 10 nodes => 1526 ms
>>>>>>> 15 nodes => 11186 ms
>>>>>>> Benchmark Displaying ManyInnerNodesAndEdges :
>>>>>>> 1 nodes => 9 ms
>>>>>>> 2 nodes => 239 ms
>>>>>>> 3 nodes => 3278 ms
>>>>>>> 4 nodes => 30492 ms
>>>>>>> Benchmark Displaying elementAt :
>>>>>>> 100 nodes => 3 ms
>>>>>>> 500 nodes => 5 ms
>>>>>>> 1000 nodes => 9 ms
>>>>>>> 1500 nodes => 11 ms
>>>>>>> 2000 nodes => 14 ms
>>>>>>> 2500 nodes => 16 ms
>>>>>>> Benchmark many small nodes :
>>>>>>> 2000 nodes => 2368 ms
>>>>>>>
>>>>>>> --
>>>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>>>>>> Alexandre Bergel  http://www.bergel.eu
>>>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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  http://www.bergel.eu
>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Moose-dev mailing list
>>>>> [hidden email]
>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>
>>>> --
>>>> www.tudorgirba.com
>>>>
>>>> "What is more important: To be happy, or to make happy?"
>>>>
>>>> _______________________________________________
>>>> Moose-dev mailing list
>>>> [hidden email]
>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>
>>> --
>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>> Alexandre Bergel  http://www.bergel.eu
>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>

> I can reproduce the problem of this double system complexity. I am  
> working on it.
>
> cheers,
> Alexandre
>
>
> On 16 Jul 2010, at 11:32, Alexandre Bergel wrote:
>
>> I tried a system complexity on the Moose model (all famix classes)  
>> and it works well...
>> I come to see you Jannik.
>>
>> Alexandre
>>
>>
>> On 16 Jul 2010, at 11:22, Laval Jannik wrote:
>>
>>> Yes, I reproduce it.
>>> In a small system complexity, the problem does not appear (Network)
>>> In Seaside, a big one (1100 classes), I have the same bug as Doru.
>>>
>>> Jannik
>>>
>>> On Jul 16, 2010, at 11:17 , Alexandre Bergel wrote:
>>>
>>>> Strange. I cannot reproduce the issue.
>>>> It works properly with me.
>>>>
>>>> Jannik, can you try to open a system complexity please?
>>>>
>>>> Cheers,
>>>> Alexandre
>>>>
>>>>
>>>> On 16 Jul 2010, at 10:56, Tudor Girba wrote:
>>>>
>>>>> Hi Alex,
>>>>>
>>>>> The new version creates serious problems for system complexity:  
>>>>> everything appears double. See the attachment.
>>>>>
>>>>> Also, in the blueprint, the bounds are again cropping the top  
>>>>> and the left side of the visualization.
>>>>>
>>>>> I tested both with the Cog and with regular VM.
>>>>>
>>>>> Cheers,
>>>>> Doru
>>>>>
>>>>> <Picture 1.png>
>>>>>
>>>>>
>>>>>
>>>>> On 16 Jul 2010, at 10:27, Alexandre Bergel wrote:
>>>>>
>>>>>>> thanks alex
>>>>>>> we are really stressing mondrian with our crazy ideas.
>>>>>>
>>>>>> Package blueprint was indeed interesting.
>>>>>> Thousands of small nodes contained in a large node, big enough  
>>>>>> to not be cached using the former system. Large nodes are now  
>>>>>> bitmap cached even if they are partially displayed. It looks  
>>>>>> obvious, but converging to this solution took time...
>>>>>>
>>>>>> Thanks for all your bug report.
>>>>>>
>>>>>> Cheers,
>>>>>> Alexandre
>>>>>>
>>>>>>>
>>>>>>> On Jul 16, 2010, at 9:31 AM, Alexandre Bergel wrote:
>>>>>>>
>>>>>>>> Dear Mondrian friends,
>>>>>>>>
>>>>>>>> A new cache mechanism has been implemented and some part have  
>>>>>>>> been simplified. The goal was to make Package blueprint fast  
>>>>>>>> without reducing the speed up for other visualization. The  
>>>>>>>> goal has been reached. On my machine, Package Blueprint is  
>>>>>>>> snappy (as soon as it got displayed and you do not select  
>>>>>>>> anything).
>>>>>>>>
>>>>>>>> The health report shown below is sensibly the same than the  
>>>>>>>> one sent few days ago. However, the new benchmark ("Benchmark  
>>>>>>>> many small nodes") is the one that reproduce a situation  
>>>>>>>> found in package blueprint. It was costly before this version.
>>>>>>>>
>>>>>>>> I would like you to try the last version of Mondrian. I  
>>>>>>>> tested it against class blueprint and it behaves as it  
>>>>>>>> should. However, you may notice some differences. Was the  
>>>>>>>> rendering and scrolling faster for you? Are you happy with  
>>>>>>>> this new version?
>>>>>>>>
>>>>>>>>
>>>>>>>> Report produced on 2010-07-16T09:13:19+02:00
>>>>>>>> System version Pharo-1.1-11400-rc2 of 12 June 2010 update 11400
>>>>>>>> Benchmark ManyNode (simple rendering of nodes) :
>>>>>>>> 100 nodes => 7 ms
>>>>>>>> 200 nodes => 12 ms
>>>>>>>> 300 nodes => 18 ms
>>>>>>>> 400 nodes => 23 ms
>>>>>>>> 500 nodes => 30 ms
>>>>>>>> 600 nodes => 35 ms
>>>>>>>> 700 nodes => 41 ms
>>>>>>>> 800 nodes => 46 ms
>>>>>>>> 900 nodes => 52 ms
>>>>>>>> 1000 nodes => 58 ms
>>>>>>>> 1600 nodes => 93 ms
>>>>>>>> 3200 nodes => 186 ms
>>>>>>>> 6400 nodes => 373 ms
>>>>>>>> Benchmark ManyEdges (simple rendering of edges) :
>>>>>>>> 10 edges => 3 ms
>>>>>>>> 20 edges => 9 ms
>>>>>>>> 30 edges => 21 ms
>>>>>>>> 40 edges => 38 ms
>>>>>>>> 50 edges => 65 ms
>>>>>>>> 60 edges => 102 ms
>>>>>>>> 70 edges => 153 ms
>>>>>>>> 80 edges => 223 ms
>>>>>>>> 90 edges => 310 ms
>>>>>>>> 100 edges => 409 ms
>>>>>>>> 200 edges => 5844 ms
>>>>>>>> 300 edges => 37619 ms
>>>>>>>> Benchmark ManyInnerNodes :
>>>>>>>> 5 nodes => 170 ms
>>>>>>>> 10 nodes => 3012 ms
>>>>>>>> 15 nodes => 11589 ms
>>>>>>>> Benchmark Displaying ManyInnerNodes :
>>>>>>>> 5 nodes => 152 ms
>>>>>>>> 10 nodes => 1526 ms
>>>>>>>> 15 nodes => 11186 ms
>>>>>>>> Benchmark Displaying ManyInnerNodesAndEdges :
>>>>>>>> 1 nodes => 9 ms
>>>>>>>> 2 nodes => 239 ms
>>>>>>>> 3 nodes => 3278 ms
>>>>>>>> 4 nodes => 30492 ms
>>>>>>>> Benchmark Displaying elementAt :
>>>>>>>> 100 nodes => 3 ms
>>>>>>>> 500 nodes => 5 ms
>>>>>>>> 1000 nodes => 9 ms
>>>>>>>> 1500 nodes => 11 ms
>>>>>>>> 2000 nodes => 14 ms
>>>>>>>> 2500 nodes => 16 ms
>>>>>>>> Benchmark many small nodes :
>>>>>>>> 2000 nodes => 2368 ms
>>>>>>>>
>>>>>>>> --
>>>>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>>>>>>> Alexandre Bergel  http://www.bergel.eu
>>>>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> 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  http://www.bergel.eu
>>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Moose-dev mailing list
>>>>>> [hidden email]
>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>
>>>>> --
>>>>> www.tudorgirba.com
>>>>>
>>>>> "What is more important: To be happy, or to make happy?"
>>>>>
>>>>> _______________________________________________
>>>>> Moose-dev mailing list
>>>>> [hidden email]
>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>
>>>> --
>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>>> Alexandre Bergel  http://www.bergel.eu
>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>
>> --
>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>> Alexandre Bergel  http://www.bergel.eu
>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>
>>
>>
>>
>>
>
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

> Thanks, Alex.
>
> Doru
>
>
> On 16 Jul 2010, at 12:00, Alexandre Bergel wrote:
>
>> I can reproduce the problem of this double system complexity. I am working on it.
>>
>> cheers,
>> Alexandre
>>
>>
>> On 16 Jul 2010, at 11:32, Alexandre Bergel wrote:
>>
>>> I tried a system complexity on the Moose model (all famix classes) and it works well...
>>> I come to see you Jannik.
>>>
>>> Alexandre
>>>
>>>
>>> On 16 Jul 2010, at 11:22, Laval Jannik wrote:
>>>
>>>> Yes, I reproduce it.
>>>> In a small system complexity, the problem does not appear (Network)
>>>> In Seaside, a big one (1100 classes), I have the same bug as Doru.
>>>>
>>>> Jannik
>>>>
>>>> On Jul 16, 2010, at 11:17 , Alexandre Bergel wrote:
>>>>
>>>>> Strange. I cannot reproduce the issue.
>>>>> It works properly with me.
>>>>>
>>>>> Jannik, can you try to open a system complexity please?
>>>>>
>>>>> Cheers,
>>>>> Alexandre
>>>>>
>>>>>
>>>>> On 16 Jul 2010, at 10:56, Tudor Girba wrote:
>>>>>
>>>>>> Hi Alex,
>>>>>>
>>>>>> The new version creates serious problems for system complexity: everything appears double. See the attachment.
>>>>>>
>>>>>> Also, in the blueprint, the bounds are again cropping the top and the left side of the visualization.
>>>>>>
>>>>>> I tested both with the Cog and with regular VM.
>>>>>>
>>>>>> Cheers,
>>>>>> Doru
>>>>>>
>>>>>> <Picture 1.png>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 16 Jul 2010, at 10:27, Alexandre Bergel wrote:
>>>>>>
>>>>>>>> thanks alex
>>>>>>>> we are really stressing mondrian with our crazy ideas.
>>>>>>>
>>>>>>> Package blueprint was indeed interesting.
>>>>>>> Thousands of small nodes contained in a large node, big enough to not be cached using the former system. Large nodes are now bitmap cached even if they are partially displayed. It looks obvious, but converging to this solution took time...
>>>>>>>
>>>>>>> Thanks for all your bug report.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Alexandre
>>>>>>>
>>>>>>>>
>>>>>>>> On Jul 16, 2010, at 9:31 AM, Alexandre Bergel wrote:
>>>>>>>>
>>>>>>>>> Dear Mondrian friends,
>>>>>>>>>
>>>>>>>>> A new cache mechanism has been implemented and some part have been simplified. The goal was to make Package blueprint fast without reducing the speed up for other visualization. The goal has been reached. On my machine, Package Blueprint is snappy (as soon as it got displayed and you do not select anything).
>>>>>>>>>
>>>>>>>>> The health report shown below is sensibly the same than the one sent few days ago. However, the new benchmark ("Benchmark many small nodes") is the one that reproduce a situation found in package blueprint. It was costly before this version.
>>>>>>>>>
>>>>>>>>> I would like you to try the last version of Mondrian. I tested it against class blueprint and it behaves as it should. However, you may notice some differences. Was the rendering and scrolling faster for you? Are you happy with this new version?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Report produced on 2010-07-16T09:13:19+02:00
>>>>>>>>> System version Pharo-1.1-11400-rc2 of 12 June 2010 update 11400
>>>>>>>>> Benchmark ManyNode (simple rendering of nodes) :
>>>>>>>>> 100 nodes => 7 ms
>>>>>>>>> 200 nodes => 12 ms
>>>>>>>>> 300 nodes => 18 ms
>>>>>>>>> 400 nodes => 23 ms
>>>>>>>>> 500 nodes => 30 ms
>>>>>>>>> 600 nodes => 35 ms
>>>>>>>>> 700 nodes => 41 ms
>>>>>>>>> 800 nodes => 46 ms
>>>>>>>>> 900 nodes => 52 ms
>>>>>>>>> 1000 nodes => 58 ms
>>>>>>>>> 1600 nodes => 93 ms
>>>>>>>>> 3200 nodes => 186 ms
>>>>>>>>> 6400 nodes => 373 ms
>>>>>>>>> Benchmark ManyEdges (simple rendering of edges) :
>>>>>>>>> 10 edges => 3 ms
>>>>>>>>> 20 edges => 9 ms
>>>>>>>>> 30 edges => 21 ms
>>>>>>>>> 40 edges => 38 ms
>>>>>>>>> 50 edges => 65 ms
>>>>>>>>> 60 edges => 102 ms
>>>>>>>>> 70 edges => 153 ms
>>>>>>>>> 80 edges => 223 ms
>>>>>>>>> 90 edges => 310 ms
>>>>>>>>> 100 edges => 409 ms
>>>>>>>>> 200 edges => 5844 ms
>>>>>>>>> 300 edges => 37619 ms
>>>>>>>>> Benchmark ManyInnerNodes :
>>>>>>>>> 5 nodes => 170 ms
>>>>>>>>> 10 nodes => 3012 ms
>>>>>>>>> 15 nodes => 11589 ms
>>>>>>>>> Benchmark Displaying ManyInnerNodes :
>>>>>>>>> 5 nodes => 152 ms
>>>>>>>>> 10 nodes => 1526 ms
>>>>>>>>> 15 nodes => 11186 ms
>>>>>>>>> Benchmark Displaying ManyInnerNodesAndEdges :
>>>>>>>>> 1 nodes => 9 ms
>>>>>>>>> 2 nodes => 239 ms
>>>>>>>>> 3 nodes => 3278 ms
>>>>>>>>> 4 nodes => 30492 ms
>>>>>>>>> Benchmark Displaying elementAt :
>>>>>>>>> 100 nodes => 3 ms
>>>>>>>>> 500 nodes => 5 ms
>>>>>>>>> 1000 nodes => 9 ms
>>>>>>>>> 1500 nodes => 11 ms
>>>>>>>>> 2000 nodes => 14 ms
>>>>>>>>> 2500 nodes => 16 ms
>>>>>>>>> Benchmark many small nodes :
>>>>>>>>> 2000 nodes => 2368 ms
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>>>>>>>> Alexandre Bergel  http://www.bergel.eu
>>>>>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> 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  http://www.bergel.eu
>>>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Moose-dev mailing list
>>>>>>> [hidden email]
>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>>
>>>>>> --
>>>>>> www.tudorgirba.com
>>>>>>
>>>>>> "What is more important: To be happy, or to make happy?"
>>>>>>
>>>>>> _______________________________________________
>>>>>> Moose-dev mailing list
>>>>>> [hidden email]
>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>
>>>>> --
>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>>>> Alexandre Bergel  http://www.bergel.eu
>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>
>>> --
>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>> Alexandre Bergel  http://www.bergel.eu
>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>>
>>>
>>>
>>>
>>>
>>
>> --
>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>> Alexandre Bergel  http://www.bergel.eu
>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> [hidden email]
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> --
> www.tudorgirba.com
>
> "Live like you mean it."
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

> Doru, Jannik,
>
> The last version of Mondrian should address this issue. There was a problem in the cache. This is now fixed. Can you confirm?
>
> Cheers,
> Alexandre
>
>
> On 16 Jul 2010, at 12:15, Tudor Girba wrote:
>
>> Thanks, Alex.
>>
>> Doru

> Hi Johan,
>
> Your problem is now solved.
>
>> I am still having the same problem in AspectMaps: If I change the contents of a node with forNode:do: the interaction specified for the new contents does not work. Below is a test case to run in the easel. Click once on a rectangle, should open it to show 3 diamonds. (first error: shows 2)
>
> The fact that you have just 2 diamonds is normal. You wrote {3.4.5} in your script, which is understood as {3.4 . 5} by the Pharo compiler. The first element is 3.4, and the second is 5.
>
>> Click on a diamond, should open it to show 4 triangles. (second error: nothing happens).
>
> Indeed. The reason is that the bitmap cache and the list of elements to lookup when you click on the screen were not reseted by forNode:do:. The tests I've written for forNode:do: did not check for this.
>
> Note that you are the only customer of forNode:do:, so you may encounter some bugs that nobody (even my tests) detected.
>
> I will be highly responsive for the next two/three weeks (half-holidays at my parents). It is a good moment for you to emit bug report. Afterward, the semester will begin and I may slow down the pace of programming sessions (hopefully not :)
>
> Regards,
> Alexandre
>
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

> Hi Alex,
>
> it's still not working for me :-( Test code is below.
> - Hover over diamonds do not show 3, 4 or 5
> - Clicking on a diamond does nothing.
>
> I tried this in v 506 and 508, same behavior.
>
> view interaction on: MOMouseDown do: [:ann |
> view forNode: ann element model do: [
> view interaction on: MOMouseDown do: [:ann2|
> view forNode: ann2 element model do: [
> view shape triangle. view nodes: #(6 7 8 9).]].
> view shape diamond. view nodes: #(3 4 5).]].
> view nodes: #(1 2)
>
> On 18 Jul 2010, at 15:38, Alexandre Bergel wrote:
>
>> Hi Johan,
>>
>> Your problem is now solved.
>>
>>> I am still having the same problem in AspectMaps: If I change the contents of a node with forNode:do: the interaction specified for the new contents does not work. Below is a test case to run in the easel. Click once on a rectangle, should open it to show 3 diamonds. (first error: shows 2)
>>
>> The fact that you have just 2 diamonds is normal. You wrote {3.4.5} in your script, which is understood as {3.4 . 5} by the Pharo compiler. The first element is 3.4, and the second is 5.
>>
>>> Click on a diamond, should open it to show 4 triangles. (second error: nothing happens).
>>
>> Indeed. The reason is that the bitmap cache and the list of elements to lookup when you click on the screen were not reseted by forNode:do:. The tests I've written for forNode:do: did not check for this.
>>
>> Note that you are the only customer of forNode:do:, so you may encounter some bugs that nobody (even my tests) detected.
>>
>> I will be highly responsive for the next two/three weeks (half-holidays at my parents). It is a good moment for you to emit bug report. Afterward, the semester will begin and I may slow down the pace of programming sessions (hopefully not :)
>>
>> Regards,
>> Alexandre
>>
>> --
>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>> Alexandre Bergel  http://www.bergel.eu
>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> [hidden email]
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> --
> 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

> OK, it seems to work now. Thanks :-)
>
> I think it would be a good idea to encapsulate the behavior of changing a node's content representation (see below for example code) in an API call, like the other 2 additions we talked about in the CLEI submission. It would be something like redrawContentsOf: aNode contentsBlock: aBlock
>
> TraitStructuralZoom>>drawExtendedContents
> "extendedContentsFor: just adds the required nodes and edges"
> aView forNode: self do: [self extendedContentsFor: aView].
> aView root allEdgesDo: #resetCache; applyLayout.
> aView updateWindow.
>
> On 20 Jul 2010, at 06:21, Alexandre Bergel wrote:
>
>> It does in my image if I drag and drop the node. But if you do not drag a node, the bounds of the root is not updated.
>> In any case, the last version should solve the problem. Try it with the code you gave, it should work.
>>
>> I added a test for this situation: testInteraction14AddingSubnodeToIncreaseRootSize
>>
>> Cheers,
>> Alexandre
>>
>
> --
> 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