Bonsoir,
je viens de me rendre compte que la période minimum que peut utiliser un morph entre deux appels à la fonction step est de 20 millisecondes (lié je suppose à la variable MinCycleLapse de la classe WorldState).
C'est à dire qu'un Morph, en parcourant l'écran pixel par pixel, ne peut pas parcourir une distance de 500 pixels (ce qui est peu) en moins de 10 secondes (c'est long).
Seule solution, créer une boucle infini et dessiner dans un canvas (FormCanvas plus précisément).
Seulement, cela bloque l'environnement et la gestion des évènements claviers par exemple me pose problème. J'ai bien essayé de jouer avec la classe Sensor, mais j'ai lu sur plusieurs site qu'il était fortement déconseillé de l'utiliser.
Du coup je suis un peu perdu et si vous avez quelques pistes à me proposer ça m'aiderai beaucoup.
J'ai bien essayé de diminuer la variable MinCycleLapse (classe WorldState, méthode initialize) à 4 au lieu de 20, mais le résultat n'est pas satisfaisant, les animations n'ont pas "un rythme" constant. Les nombreux évènements doivent se sentir un peu à l'étroit dans cette fenêtre de temps de 4ms.
Merci.
Cordialement, -- Frédéric
salut frederic
Tu devrais demander dans la mailing-list squeak-dev ou pharo. Pour ma part, je pense que Morph est trop gros trop gras... Apres c'est rare de bouger pixels par pixels.
Stef
On Jun 7, 2009, at 9:15 PM, Frédéric Ferrère wrote:
Bonsoir,
je viens de me rendre compte que la période minimum que peut utiliser un morph entre deux appels à la fonction step est de 20 millisecondes (lié je suppose à la variable MinCycleLapse de la classe WorldState).
C'est à dire qu'un Morph, en parcourant l'écran pixel par pixel, ne peut pas parcourir une distance de 500 pixels (ce qui est peu) en moins de 10 secondes (c'est long).
Seule solution, créer une boucle infini et dessiner dans un canvas (FormCanvas plus précisément).
Seulement, cela bloque l'environnement et la gestion des évènements claviers par exemple me pose problème. J'ai bien essayé de jouer avec la classe Sensor, mais j'ai lu sur plusieurs site qu'il était fortement déconseillé de l'utiliser.
Du coup je suis un peu perdu et si vous avez quelques pistes à me proposer ça m'aiderai beaucoup.
J'ai bien essayé de diminuer la variable MinCycleLapse (classe WorldState, méthode initialize) à 4 au lieu de 20, mais le résultat n'est pas satisfaisant, les animations n'ont pas "un rythme" constant. Les nombreux évènements doivent se sentir un peu à l'étroit dans cette fenêtre de temps de 4ms.
Merci.
Cordialement,
Frédéric _______________________________________________ Squeak-fr mailing list Squeak-fr@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/squeak-fr
2009/6/7 Frédéric Ferrère frederic.ferrere@free.fr:
je viens de me rendre compte que la période minimum que peut utiliser un morph entre deux appels à la fonction step est de 20 millisecondes (lié je suppose à la variable MinCycleLapse de la classe WorldState).
Ça paraît étonnant car si je déplace un morph à la souris, ça va plus vite que ça.
Damien Cassou a écrit :
2009/6/7 Frédéric Ferrère frederic.ferrere@free.fr:
je viens de me rendre compte que la période minimum que peut utiliser un morph entre deux appels à la fonction step est de 20 millisecondes (lié je suppose à la variable MinCycleLapse de la classe WorldState).
Ça paraît étonnant car si je déplace un morph à la souris, ça va plus vite que ça.
Peut être que : - les déplacements ne se font pas pixel par pixel. - les évènements souris sont capturés à un intervalle de temps plus court.
Dans l'exemple ci-dessous, un petit carré rouge va se déplacer dans un rectangle noir de 50 pixels vers la droite et je fais varier plusieurs fois la valeur de stepTime, les résultats sont assez loin de l'effet souhaité.
avec stepTime <= 30ms (0,5,10,15,20 ou 30) impossible d'avoir moins de 2s pour ce déplacement de 50 pixels. avec stepTime = 60ms, le déplacement prends 4s (au lieu de 3s). avec stepTime = 100ms, le déplacement prends 6s (au lieu de 5s).
Environnement: - OS : Linux Ubuntu 9.04 - VM : exupery - image : Pharo0.1 Latest update: #10320
========================================== PasteUpMorph subclass: #MorphSpeedTest instanceVariableNames: 'rectangle actions startTime actIndex delay' classVariableNames: '' poolDictionaries: '' category: 'SpeedTests' ................................................................ initialize super initialize. self stopStepping. self extent: 600@100; color: Color black. rectangle := RectangleMorph new extent: 30@30; position: 0@35; color: Color red. self addMorph: rectangle. actions := OrderedCollection new. actIndex := 1. delay := 20. self actionSetTime. self actionMove. self actionPrint. self actionDelayZero.
self actionResetPos. self actionSetTime. self actionMove. self actionPrint. self actionDelayTen.
self actionResetPos. self actionSetTime. self actionMove. self actionPrint. self actionDelaySixty.
self actionResetPos. self actionSetTime. self actionMove. self actionPrint.
self actionEnd. ................................................................ step (actions at: actIndex) value: self ................................................................ stepTime ^delay ................................................................ actionSetTime actions add: [:act| self startTime: (Time millisecondClockValue). actIndex := actIndex + 1. ]. ................................................................ actionResetPos actions add: [:act| rectangle position: 0@35. actIndex := actIndex + 1.]. ................................................................ actionPrint actions add: [:act| | cycle | cycle := Time millisecondClockValue - act startTime. Transcript show: (cycle);cr. Transcript show: act rectangle position;cr. actIndex := actIndex + 1.]. ................................................................ actionMove 1 to: 50 do: [ :nb| actions add: [:act| rectangle position: (rectangle position + (1@0)). actIndex := actIndex + 1.].]. ................................................................ actionEnd actions add: [:act| act delete]. ................................................................ actionDelayTen actions add: [:act| delay := 10. actIndex := actIndex + 1.]. ................................................................
Cordialement, -- Frédéric
pour voir la vitesse maximum que tu peux atteindre pixel par pixel, essaie ceci dans un workspace:
(m := Morph new) openInWorld. 1 to: 300 do: [:i | m position: m position + (1@1). World doOneCycle]
Stef
Salut,
Tu peux tenter un MessageTally:
MessageTally spyOn:[ (m := Morph new) openInWorld. 1 to: 300 do: [:i | m position: m position + (1@1). World doOneCycle]].
Sous Pharo j'ai eu ces résultats:
======== ======== - 5992 tallies, 6074 msec.
**Tree** 99.5% {6044ms} PasteUpMorph>>doOneCycle 99.5% {6044ms} WorldState>>doOneCycleFor: 85.3% {5181ms} WorldState>>interCyclePause: |85.3% {5181ms} Delay>>wait | 83.5% {5072ms} primitives 14.1% {856ms} WorldState>>doOneCycleNowFor:
**Leaves** 83.5% {5072ms} Delay>>wait
**Memory** old +117,904 bytes young +39,708 bytes used +157,612 bytes free -157,612 bytes
**GCs** full 0 totalling 0ms (0.0% uptime) incr 374 totalling 96ms (2.0% uptime), avg 0.0ms tenures 2 (avg 187 GCs/tenure) root table 0 overflows ======== ========
En gros, il passe la plupart de son temps dans la méthode interCyclePause: L'appel à cette méthode dépend de la préférence "higherPerformance".
En activant cette préférence, les résultats sont bien meilleurs, mais avec certainement des ralentissements:
======== ========
- 847 tallies, 847 msec.
**Tree** 99.3% {841ms} PasteUpMorph>>doOneCycle 99.3% {841ms} WorldState>>doOneCycleFor: 98.8% {837ms} WorldState>>doOneCycleNowFor:
======== ========
Jannik
On 9 juin 09, at 08:57, Stéphane Rollandin wrote:
pour voir la vitesse maximum que tu peux atteindre pixel par pixel, essaie ceci dans un workspace:
(m := Morph new) openInWorld. 1 to: 300 do: [:i | m position: m position + (1@1). World doOneCycle]
Stef
Squeak-fr mailing list Squeak-fr@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/squeak-fr
--- Jannik Laval PhD Student - Rmod Team - INRIA Certified Project Management Associate (IPMA) http://www.jannik-laval.eu http://rmod.lille.inria.fr ---
Bonjour,
Visuellement c'est lent. :)
avec cet exemple on obtient un déplacement qui dure 6s. 300 pixels / 6074ms = 20ms cqfd ------
Cycle minimal = 20ms.
Laval Jannik a écrit :
Salut,
Tu peux tenter un MessageTally:
MessageTally spyOn:[ (m := Morph new) openInWorld. 1 to: 300 do: [:i | m position: m position + (1@1). World doOneCycle]].
Sous Pharo j'ai eu ces résultats:
========
- 5992 tallies, 6074 msec.
==== Cordialement,
Visuellement c'est lent. :)
avec cet exemple on obtient un déplacement qui dure 6s. 300 pixels / 6074ms = 20ms cqfd
il faut que Preferences higherPerformance soit true, sinon tu te retrouve avec le MinCycleLapse de 20 ms.
d'autre part, le World doOneCycle redessine la partie du Display traversée par le Morph. il va donc plus vite si le Project est vide (au moins sur sa trajectoire)
dans ce contexte-là, le code
[ (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
Stef
Bonsoir,
je viens de tester ce morceau de code en ayant pris soin d'activer Preferences higherPerformance :
* 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.
Par contre, il y a quand même un nette différence entre les deux environnements de test, squeak vs pharo, lorsque le world est vide. C'est grave docteur ? :)
Pour finir, ce qui m'intéresse c'est une animation à l'intérieur d'un morph de 600 pixels par 400 pixels. [ |p| p := PasteUpMorph new extent: 600@400; color: Color black; openInWorld. p addMorph: (m := Morph new).
1 to: 300 do: [:i |
m position: m position + (1@1).
World doOneCycle] ] durationToRun
Et dans ce cas les temps obtenus ne sont pas très bon : 4 secondes.
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
moi je suis sous Windows Vista, vm 3.9.2, et avec une image fraiche Squeak3.10.2-7179-basic j'ai:
Test 1 0:00:00:00.4 Test 2 0:00:00:00.86
donc on a pas du tout la même expérience...
Stef
Frédéric Ferrère a écrit :
- 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
- 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
est-ce que tu peux envoyer tes resultats sur la mailing-list pharo car avoir un system rapide nous interesse.
On Jun 11, 2009, at 10:39 PM, Frédéric Ferrère wrote:
Bonsoir,
je viens de tester ce morceau de code en ayant pris soin d'activer Preferences higherPerformance :
- 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.
Par contre, il y a quand même un nette différence entre les deux environnements de test, squeak vs pharo, lorsque le world est vide. C'est grave docteur ? :)
Pour finir, ce qui m'intéresse c'est une animation à l'intérieur d'un morph de 600 pixels par 400 pixels. [ |p| p := PasteUpMorph new extent: 600@400; color: Color black; openInWorld. p addMorph: (m := Morph new). 1 to: 300 do: [:i | m position: m position + (1@1). World doOneCycle] ] durationToRun
Et dans ce cas les temps obtenus ne sont pas très bon : 4 secondes.
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
Squeak-fr mailing list Squeak-fr@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/squeak-fr
frederic
je sais qu'un enh (832 dans http://code.google.com/p/pharo/issues/) a ralenti pharo. Donc on va regarde cela et tes petits morceaux de code sont bien pour cela.
Stef
On Jun 11, 2009, at 10:39 PM, Frédéric Ferrère wrote:
Bonsoir,
je viens de tester ce morceau de code en ayant pris soin d'activer Preferences higherPerformance :
- 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.
Par contre, il y a quand même un nette différence entre les deux environnements de test, squeak vs pharo, lorsque le world est vide. C'est grave docteur ? :)
Pour finir, ce qui m'intéresse c'est une animation à l'intérieur d'un morph de 600 pixels par 400 pixels. [ |p| p := PasteUpMorph new extent: 600@400; color: Color black; openInWorld. p addMorph: (m := Morph new). 1 to: 300 do: [:i | m position: m position + (1@1). World doOneCycle] ] durationToRun
Et dans ce cas les temps obtenus ne sont pas très bon : 4 secondes.
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
Squeak-fr mailing list Squeak-fr@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/squeak-fr
avec 10333 pharo et higherPerformance on j'ai pour le premier
0:00:00:00.409
pour le second
0:00:00:00.351
stef
On Jun 11, 2009, at 10:39 PM, Frédéric Ferrère wrote:
Bonsoir,
je viens de tester ce morceau de code en ayant pris soin d'activer Preferences higherPerformance :
- 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.
Par contre, il y a quand même un nette différence entre les deux environnements de test, squeak vs pharo, lorsque le world est vide. C'est grave docteur ? :)
Pour finir, ce qui m'intéresse c'est une animation à l'intérieur d'un morph de 600 pixels par 400 pixels. [ |p| p := PasteUpMorph new extent: 600@400; color: Color black; openInWorld. p addMorph: (m := Morph new). 1 to: 300 do: [:i | m position: m position + (1@1). World doOneCycle] ] durationToRun
Et dans ce cas les temps obtenus ne sont pas très bon : 4 secondes.
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
Squeak-fr mailing list Squeak-fr@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/squeak-fr
Un test de plus :
Sous windows XP, test 1 et test 2 sont globalement équivalents à 0:00:00:00.580.
VM : SqueakVM-Win32-3.11.2-bin Image : pharo0.1-10332dev09.06.2
Mon environnement de travail étant Gnu/Linux(Ubuntu 9.04) je suis frustré du comportement plus efficace sous windows.
La VM windows plus performante que la vm linux ?
Frédéric
je ne sais pas. je ne vois pas pourquoi techniquement
Un test de plus :
Sous windows XP, test 1 et test 2 sont globalement équivalents à 0:00:00:00.580.
VM : SqueakVM-Win32-3.11.2-bin Image : pharo0.1-10332dev09.06.2
Mon environnement de travail étant Gnu/Linux(Ubuntu 9.04) je suis frustré du comportement plus efficace sous windows.
La VM windows plus performante que la vm linux ?
Frédéric
Squeak-fr mailing list Squeak-fr@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/squeak-fr
squeak-fr@lists.squeakfoundation.org
-
Damien Cassou -
FERRERE Frédéric -
Frédéric Ferrère
-
Laval Jannik -
stephane ducasse -
Stéphane Rollandin