I tried in 10304 (since the fix 832 was introduced in 312). update10312 "self new update10312" self withUpdateLog:'- 819 argumentCount - stef fixing his methods (tests) - Issue 820: Re-implement Boolean>>#==> that was removed because it was not license clean - Issue 821: Preference to settings refactoring: #confirmFirstUseOfStyle case- Issue 657: About dialog is too big http://code.google.com/p/pharo/issues/detail?id=657 - Issue 832: morphs do not respect the damagerect http://code.google.com/p/pharo/issues/detail?id=832 But the results are the same 0:00:00:06.6055 quite bad :(
Hi guys
could you run the following:
[ (m := Morph new) openInWorld. 1 to: 300 do: [:i | m position: m position + (1@1). World doOneCycle] ] durationToRun
because frederic.ferrere@free.fr did it and here are the result
* vm : pharo-vm-0.15.1b-linux * image : pharo0.1-10332dev09.06.2 - Test 1 : Project est vide, juste le workspace ouvert à l'opposé du trajet Résultat 0:00:00:07.704 - Test 2 : ClassBrowser recouvrant tout le 'World' Résultat : 0:00:00:00.689
- Test 1 * vm : squeak3.9.8-3ubuntu3 * image : Squeak-dev 3.10.2 - Test 1 : Project est vide, juste le workspace ouvert à l'opposé du trajet Résultat : 0:00:00:02.098 - Test 2 : ClassBrowser recouvrant tout le 'World' Résultat : 0:00:00:00.608 Donc contrairement à ce qu'il semblait être logique, le morph avance plus vite si le "World" n'est pas vide.
Stéphane Rollandin a écrit :
[ (m := Morph new) openInWorld. 1 to: 300 do: [:i | m position: m position + (1@1). World doOneCycle] ] durationToRun
retourne 0:00:00:00.373 dans mon image, soit un gros tiers de seconde. on est loin des 6 s
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project