Force Base Layout is now 33 faster (in some cases)
Locked
 
|
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 [hidden email] https://www.list.inf.unibe.ch/listinfo/moose-dev |
|
|
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 <[hidden email]> 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 > [hidden email] > 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 [hidden email] https://www.list.inf.unibe.ch/listinfo/moose-dev |
Re: Force Base Layout is now 33 faster (in some cases)
|
|
In reply to this post by abergel
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 <[hidden email]> 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 > [hidden email] > https://www.list.inf.unibe.ch/listinfo/moose-dev -- www.tudorgirba.com "Speaking louder won't make the point worthier." _______________________________________________ Moose-dev mailing list [hidden email] https://www.list.inf.unibe.ch/listinfo/moose-dev |
|
|
> 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 <[hidden email]> 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 >> [hidden email] >> https://www.list.inf.unibe.ch/listinfo/moose-dev > > -- > www.tudorgirba.com > > "Speaking louder won't make the point worthier." > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.list.inf.unibe.ch/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Moose-dev mailing list [hidden email] https://www.list.inf.unibe.ch/listinfo/moose-dev |
|
|
In reply to this post by jfabry
> 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 <[hidden email]> 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 >> [hidden email] >> 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 > [hidden email] > https://www.list.inf.unibe.ch/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Moose-dev mailing list [hidden email] https://www.list.inf.unibe.ch/listinfo/moose-dev |
Re: Force Base Layout is now 33 faster (in some cases)
|
|
In reply to this post by abergel
Then we should just replace the existing one, right?
Doru > On Dec 8, 2015, at 3:57 PM, Alexandre Bergel <[hidden email]> 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 <[hidden email]> 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 >>> [hidden email] >>> https://www.list.inf.unibe.ch/listinfo/moose-dev >> >> -- >> www.tudorgirba.com >> >> "Speaking louder won't make the point worthier." >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.list.inf.unibe.ch/listinfo/moose-dev > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.list.inf.unibe.ch/listinfo/moose-dev -- www.tudorgirba.com "Speaking louder won't make the point worthier." _______________________________________________ Moose-dev mailing list [hidden email] https://www.list.inf.unibe.ch/listinfo/moose-dev |
Re: Force Base Layout is now 33 faster (in some cases)
|
|
In reply to this post by abergel
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? -- Cyril Ferlicot http://www.synectique.eu 165 Avenue Bretagne Lille 59000 France _______________________________________________ Moose-dev mailing list [hidden email] https://www.list.inf.unibe.ch/listinfo/moose-dev |
signature.asc (836 bytes) |
|
In reply to this post by Tudor Girba-2
Yes
Alexandre > On Dec 8, 2015, at 6:02 PM, Tudor Girba <[hidden email]> wrote: > > Then we should just replace the existing one, right? > > Doru > > >> On Dec 8, 2015, at 3:57 PM, Alexandre Bergel <[hidden email]> 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 <[hidden email]> 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 >>>> [hidden email] >>>> https://www.list.inf.unibe.ch/listinfo/moose-dev >>> >>> -- >>> www.tudorgirba.com >>> >>> "Speaking louder won't make the point worthier." >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> [hidden email] >>> https://www.list.inf.unibe.ch/listinfo/moose-dev >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.list.inf.unibe.ch/listinfo/moose-dev > > -- > www.tudorgirba.com > > "Speaking louder won't make the point worthier." > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.list.inf.unibe.ch/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Moose-dev mailing list [hidden email] https://www.list.inf.unibe.ch/listinfo/moose-dev |
|
|
In reply to this post by CyrilFerlicot
> 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 > > http://www.synectique.eu > > 165 Avenue Bretagne > Lille 59000 France > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.list.inf.unibe.ch/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Moose-dev mailing list [hidden email] https://www.list.inf.unibe.ch/listinfo/moose-dev |
Re: Force Base Layout is now 33 faster (in some cases)
|
|
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 > > 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 http://www.synectique.eu 165 Avenue Bretagne Lille 59000 France _______________________________________________ Moose-dev mailing list [hidden email] https://www.list.inf.unibe.ch/listinfo/moose-dev |
|
|
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 <[hidden email]> 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 > > http://www.synectique.eu > > 165 Avenue Bretagne > Lille 59000 France > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.list.inf.unibe.ch/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Moose-dev mailing list [hidden email] 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 <[hidden email]> 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 <[hidden email]> 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 >> >> http://www.synectique.eu >> >> 165 Avenue Bretagne >> Lille 59000 France >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.list.inf.unibe.ch/listinfo/moose-dev > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > 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 [hidden email] https://www.list.inf.unibe.ch/listinfo/moose-dev |
Re: Force Base Layout is now 33 faster (in some cases)
|
|
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 <[hidden email]>:
Guillaume Larcheveque
_______________________________________________ Moose-dev mailing list [hidden email] https://www.list.inf.unibe.ch/listinfo/moose-dev |
Re: Force Base Layout is now 33 faster (in some cases)
|
|
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 <[hidden email]>: > > > > > 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 <[hidden email]> > > 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 <[hidden email]> > > 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 > > >> > > >> http://www.synectique.eu > > >> > > >> 165 Avenue Bretagne > > >> Lille 59000 France > > >> > > >> _______________________________________________ > > >> Moose-dev mailing list > > >> [hidden email] > > >> https://www.list.inf.unibe.ch/listinfo/moose-dev > > > > > > -- > > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > > Alexandre Bergel http://www.bergel.eu > > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > > > > _______________________________________________ > > > Moose-dev mailing list > > > [hidden email] > > > 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 > > [hidden email] > > https://www.list.inf.unibe.ch/listinfo/moose-dev > > > > > > -- > *Guillaume Larcheveque* > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.list.inf.unibe.ch/listinfo/moose-dev -- Peter _______________________________________________ Moose-dev mailing list [hidden email] https://www.list.inf.unibe.ch/listinfo/moose-dev |
«
Return to Moose
|
1 view|%1 views
| Free forum by Nabble | Edit this page |