Hi!
I have found a nasty situation that may occurs when using composite shapes.
Consider the following script: [ b := RTMondrian new. b shape box size: 30; color: Color red trans; withText. b nodes: (1 to: 20). b edges connectFrom: [ :v | v // 3 ]. b build. RTForceBasedLayout new "doNotUseProgressBar;" on: b view elements. b view] timeToRun => 0:00:00:10.386
[ b := RTMondrian new. b shape box size: 30; color: Color red trans; withText. b nodes: (1 to: 20). b edges connectFrom: [ :v | v // 3 ]. b build. RTOptimizedForceBasedLayout new "doNotUseProgressBar;" on: b view elements. b view] timeToRun 0:00:00:00.387
Yes, on this example, the class RTOptimizedForceBasedLayout is 33 faster than the traditional layout.
The problem is that translating a composite shape is much slower than translating a non-composite shape. I have created mock elements and mock edges. That is a good news :-)
Cheers, Alexandre
Cool that you found such a radical speedup. :-) But now the question is: how do I know if I have the same problem? Is this only for RTMondrian? How do I fix it if I have it?
On Dec 7, 2015, at 23:10, Alexandre Bergel alexandre.bergel@me.com wrote:
Hi!
I have found a nasty situation that may occurs when using composite shapes.
Consider the following script: [ b := RTMondrian new. b shape box size: 30; color: Color red trans; withText. b nodes: (1 to: 20). b edges connectFrom: [ :v | v // 3 ]. b build. RTForceBasedLayout new "doNotUseProgressBar;" on: b view elements. b view] timeToRun => 0:00:00:10.386
[ b := RTMondrian new. b shape box size: 30; color: Color red trans; withText. b nodes: (1 to: 20). b edges connectFrom: [ :v | v // 3 ]. b build. RTOptimizedForceBasedLayout new "doNotUseProgressBar;" on: b view elements. b view] timeToRun 0:00:00:00.387
Yes, on this example, the class RTOptimizedForceBasedLayout is 33 faster than the traditional layout.
The problem is that translating a composite shape is much slower than translating a non-composite shape. I have created mock elements and mock edges. That is a good news :-)
Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
---> Save our in-boxes! http://emailcharter.org <---
Johan Fabry - http://pleiad.cl/~jfabry PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile
Cool that you found such a radical speedup. :-) But now the question is: how do I know if I have the same problem? Is this only for RTMondrian? How do I fix it if I have it?
I think the problem is only with the force base layout, because this it is an iterative layout made of small incremental step. And doing a translation of an element with a composed shape then this is costly.
I think that only the force base layout had this problem. The layout builder uses it now, so this is not related to Mondrian.
Alexandre
On Dec 7, 2015, at 23:10, Alexandre Bergel alexandre.bergel@me.com wrote:
Hi!
I have found a nasty situation that may occurs when using composite shapes.
Consider the following script: [ b := RTMondrian new. b shape box size: 30; color: Color red trans; withText. b nodes: (1 to: 20). b edges connectFrom: [ :v | v // 3 ]. b build. RTForceBasedLayout new "doNotUseProgressBar;" on: b view elements. b view] timeToRun => 0:00:00:10.386
[ b := RTMondrian new. b shape box size: 30; color: Color red trans; withText. b nodes: (1 to: 20). b edges connectFrom: [ :v | v // 3 ]. b build. RTOptimizedForceBasedLayout new "doNotUseProgressBar;" on: b view elements. b view] timeToRun 0:00:00:00.387
Yes, on this example, the class RTOptimizedForceBasedLayout is 33 faster than the traditional layout.
The problem is that translating a composite shape is much slower than translating a non-composite shape. I have created mock elements and mock edges. That is a good news :-)
Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
---> Save our in-boxes! http://emailcharter.org <---
Johan Fabry - http://pleiad.cl/~jfabry PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Hi,
Cool. Is there a downside of using the Optimized version as the default version?
Cheers, Doru
On Dec 7, 2015, at 9:10 PM, Alexandre Bergel alexandre.bergel@me.com wrote:
Hi!
I have found a nasty situation that may occurs when using composite shapes.
Consider the following script: [ b := RTMondrian new. b shape box size: 30; color: Color red trans; withText. b nodes: (1 to: 20). b edges connectFrom: [ :v | v // 3 ]. b build. RTForceBasedLayout new "doNotUseProgressBar;" on: b view elements. b view] timeToRun => 0:00:00:10.386
[ b := RTMondrian new. b shape box size: 30; color: Color red trans; withText. b nodes: (1 to: 20). b edges connectFrom: [ :v | v // 3 ]. b build. RTOptimizedForceBasedLayout new "doNotUseProgressBar;" on: b view elements. b view] timeToRun 0:00:00:00.387
Yes, on this example, the class RTOptimizedForceBasedLayout is 33 faster than the traditional layout.
The problem is that translating a composite shape is much slower than translating a non-composite shape. I have created mock elements and mock edges. That is a good news :-)
Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
-- www.tudorgirba.com
"Speaking louder won't make the point worthier."
Cool. Is there a downside of using the Optimized version as the default version?
No downside as far as I can see.
Alexandre
Cheers, Doru
On Dec 7, 2015, at 9:10 PM, Alexandre Bergel alexandre.bergel@me.com wrote:
Hi!
I have found a nasty situation that may occurs when using composite shapes.
Consider the following script: [ b := RTMondrian new. b shape box size: 30; color: Color red trans; withText. b nodes: (1 to: 20). b edges connectFrom: [ :v | v // 3 ]. b build. RTForceBasedLayout new "doNotUseProgressBar;" on: b view elements. b view] timeToRun => 0:00:00:10.386
[ b := RTMondrian new. b shape box size: 30; color: Color red trans; withText. b nodes: (1 to: 20). b edges connectFrom: [ :v | v // 3 ]. b build. RTOptimizedForceBasedLayout new "doNotUseProgressBar;" on: b view elements. b view] timeToRun 0:00:00:00.387
Yes, on this example, the class RTOptimizedForceBasedLayout is 33 faster than the traditional layout.
The problem is that translating a composite shape is much slower than translating a non-composite shape. I have created mock elements and mock edges. That is a good news :-)
Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
-- www.tudorgirba.com
"Speaking louder won't make the point worthier."
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Then we should just replace the existing one, right?
Doru
On Dec 8, 2015, at 3:57 PM, Alexandre Bergel alexandre.bergel@me.com wrote:
Cool. Is there a downside of using the Optimized version as the default version?
No downside as far as I can see.
Alexandre
Cheers, Doru
On Dec 7, 2015, at 9:10 PM, Alexandre Bergel alexandre.bergel@me.com wrote:
Hi!
I have found a nasty situation that may occurs when using composite shapes.
Consider the following script: [ b := RTMondrian new. b shape box size: 30; color: Color red trans; withText. b nodes: (1 to: 20). b edges connectFrom: [ :v | v // 3 ]. b build. RTForceBasedLayout new "doNotUseProgressBar;" on: b view elements. b view] timeToRun => 0:00:00:10.386
[ b := RTMondrian new. b shape box size: 30; color: Color red trans; withText. b nodes: (1 to: 20). b edges connectFrom: [ :v | v // 3 ]. b build. RTOptimizedForceBasedLayout new "doNotUseProgressBar;" on: b view elements. b view] timeToRun 0:00:00:00.387
Yes, on this example, the class RTOptimizedForceBasedLayout is 33 faster than the traditional layout.
The problem is that translating a composite shape is much slower than translating a non-composite shape. I have created mock elements and mock edges. That is a good news :-)
Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
-- www.tudorgirba.com
"Speaking louder won't make the point worthier."
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
-- www.tudorgirba.com
"Speaking louder won't make the point worthier."
Yes
Alexandre
On Dec 8, 2015, at 6:02 PM, Tudor Girba tudor@tudorgirba.com wrote:
Then we should just replace the existing one, right?
Doru
On Dec 8, 2015, at 3:57 PM, Alexandre Bergel alexandre.bergel@me.com wrote:
Cool. Is there a downside of using the Optimized version as the default version?
No downside as far as I can see.
Alexandre
Cheers, Doru
On Dec 7, 2015, at 9:10 PM, Alexandre Bergel alexandre.bergel@me.com wrote:
Hi!
I have found a nasty situation that may occurs when using composite shapes.
Consider the following script: [ b := RTMondrian new. b shape box size: 30; color: Color red trans; withText. b nodes: (1 to: 20). b edges connectFrom: [ :v | v // 3 ]. b build. RTForceBasedLayout new "doNotUseProgressBar;" on: b view elements. b view] timeToRun => 0:00:00:10.386
[ b := RTMondrian new. b shape box size: 30; color: Color red trans; withText. b nodes: (1 to: 20). b edges connectFrom: [ :v | v // 3 ]. b build. RTOptimizedForceBasedLayout new "doNotUseProgressBar;" on: b view elements. b view] timeToRun 0:00:00:00.387
Yes, on this example, the class RTOptimizedForceBasedLayout is 33 faster than the traditional layout.
The problem is that translating a composite shape is much slower than translating a non-composite shape. I have created mock elements and mock edges. That is a good news :-)
Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
-- www.tudorgirba.com
"Speaking louder won't make the point worthier."
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
-- www.tudorgirba.com
"Speaking louder won't make the point worthier."
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Le 08/12/2015 21:57, Alexandre Bergel a écrit :
Cool. Is there a downside of using the Optimized version as the default version?
No downside as far as I can see.
Alexandre
So why create a new class instead of updating the existing one?
So why create a new class instead of updating the existing one?
Because I have not tested it enough. Moreover, I feel this may impact the continuous layout one may have.
Inspect the following expression: RTGeneralExample new forceBasedLayout
The optimized layout may not be efficient here.
Alexandre
-- Cyril Ferlicot
165 Avenue Bretagne Lille 59000 France
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Le 08/12/2015 22:24, Alexandre Bergel a écrit :
So why create a new class instead of updating the existing one?
Because I have not tested it enough. Moreover, I feel this may impact the continuous layout one may have.
Inspect the following expression: RTGeneralExample new forceBasedLayout
The optimized layout may not be efficient here.
Alexandre
IMO this is why we have stable/development version for a project. If we decide that it is stable nobody have to change it and during the development phase everyone can test it/improve it without problem using the development version of Roassal. But this is just my opinion :)
Well… If something care about creating a stable and development version. Then sure, why not…
Alexandre
On Dec 8, 2015, at 6:42 PM, Ferlicot D. Cyril cyril.ferlicot@gmail.com wrote:
Le 08/12/2015 22:24, Alexandre Bergel a écrit :
So why create a new class instead of updating the existing one?
Because I have not tested it enough. Moreover, I feel this may impact the continuous layout one may have.
Inspect the following expression: RTGeneralExample new forceBasedLayout
The optimized layout may not be efficient here.
Alexandre
IMO this is why we have stable/development version for a project. If we decide that it is stable nobody have to change it and during the development phase everyone can test it/improve it without problem using the development version of Roassal. But this is just my opinion :)
-- Cyril Ferlicot
165 Avenue Bretagne Lille 59000 France
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Are you going to maintain 2 versions of a force based layout? My guess is that the answer to that is no. I would replace the old one with the optimized version.
On Dec 8, 2015, at 19:29, Alexandre Bergel alexandre.bergel@me.com wrote:
Well… If something care about creating a stable and development version. Then sure, why not…
Alexandre
On Dec 8, 2015, at 6:42 PM, Ferlicot D. Cyril cyril.ferlicot@gmail.com wrote:
Le 08/12/2015 22:24, Alexandre Bergel a écrit :
So why create a new class instead of updating the existing one?
Because I have not tested it enough. Moreover, I feel this may impact the continuous layout one may have.
Inspect the following expression: RTGeneralExample new forceBasedLayout
The optimized layout may not be efficient here.
Alexandre
IMO this is why we have stable/development version for a project. If we decide that it is stable nobody have to change it and during the development phase everyone can test it/improve it without problem using the development version of Roassal. But this is just my opinion :)
-- Cyril Ferlicot
165 Avenue Bretagne Lille 59000 France
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
---> Save our in-boxes! http://emailcharter.org <---
Johan Fabry - http://pleiad.cl/~jfabry PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile
You still have a #stable and #development versions in ConfigurationOfRoassal2 (created by Chris Andrei) :)
In my opinion you should really optimize #encompassingRectangle in TRCompositeShape and use relative position for sub elements. In addition a cache would be great for this.
2015-12-09 0:35 GMT+01:00 Johan Fabry jfabry@dcc.uchile.cl:
Are you going to maintain 2 versions of a force based layout? My guess is that the answer to that is no. I would replace the old one with the optimized version.
On Dec 8, 2015, at 19:29, Alexandre Bergel alexandre.bergel@me.com
wrote:
Well… If something care about creating a stable and development version.
Then sure, why not…
Alexandre
On Dec 8, 2015, at 6:42 PM, Ferlicot D. Cyril cyril.ferlicot@gmail.com
wrote:
Le 08/12/2015 22:24, Alexandre Bergel a écrit :
So why create a new class instead of updating the existing one?
Because I have not tested it enough. Moreover, I feel this may impact
the continuous layout one may have.
Inspect the following expression: RTGeneralExample new forceBasedLayout
The optimized layout may not be efficient here.
Alexandre
IMO this is why we have stable/development version for a project. If we decide that it is stable nobody have to change it and during the development phase everyone can test it/improve it without problem using the development version of Roassal. But this is just my opinion :)
-- Cyril Ferlicot
165 Avenue Bretagne Lille 59000 France
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
---> Save our in-boxes! http://emailcharter.org <---
Johan Fabry - http://pleiad.cl/~jfabry PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
On 12/09, Guillaume Larcheveque wrote:
You still have a #stable and #development versions in ConfigurationOfRoassal2 (created by Chris Andrei) :)
In my opinion you should really optimize #encompassingRectangle in TRCompositeShape and use relative position for sub elements. In addition a cache would be great for this.
I don't know what are the improvements in the optimized layout, but is there a reason why you are physically (in canvas) moving the elements during the iterations?
Wouldn't it be faster to have a dual representation of the shapes in the quad tree and move the real shapes only at the very end?
That way you could compute the #encompassingRectangle rectangle once for all shapes (labels are also very slow) and work in the layout just with Rectangles.
2015-12-09 0:35 GMT+01:00 Johan Fabry jfabry@dcc.uchile.cl:
Are you going to maintain 2 versions of a force based layout? My guess is that the answer to that is no. I would replace the old one with the optimized version.
On Dec 8, 2015, at 19:29, Alexandre Bergel alexandre.bergel@me.com
wrote:
Well… If something care about creating a stable and development version.
Then sure, why not…
Alexandre
On Dec 8, 2015, at 6:42 PM, Ferlicot D. Cyril cyril.ferlicot@gmail.com
wrote:
Le 08/12/2015 22:24, Alexandre Bergel a écrit :
So why create a new class instead of updating the existing one?
Because I have not tested it enough. Moreover, I feel this may impact
the continuous layout one may have.
Inspect the following expression: RTGeneralExample new forceBasedLayout
The optimized layout may not be efficient here.
Alexandre
IMO this is why we have stable/development version for a project. If we decide that it is stable nobody have to change it and during the development phase everyone can test it/improve it without problem using the development version of Roassal. But this is just my opinion :)
-- Cyril Ferlicot
165 Avenue Bretagne Lille 59000 France
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
---> Save our in-boxes! http://emailcharter.org <---
Johan Fabry - http://pleiad.cl/~jfabry PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
-- *Guillaume Larcheveque*
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
-
Alexandre Bergel -
Ferlicot D. Cyril -
Guillaume Larcheveque -
Johan Fabry -
Peter Uhnak -
Tudor Girba