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
>>>> Moose-dev(a)iam.unibe.ch
>>>>
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> Moose-dev(a)iam.unibe.ch
>>>
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>> --
>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>> Alexandre Bergel
http://www.bergel.eu
>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> Moose-dev(a)iam.unibe.ch
>>
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
> Moose-dev(a)iam.unibe.ch
>
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel
http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
---
Jannik Laval
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch