Les gars... Vous avez bien conscience que cette boucle qui gère les événements n'est pas exécutée indéfiniment le plus vite possible dans une boucle infinie sans rien à côté. Auquel cas, effectivement, ça chargerait le CPU à 100%,
comme n'importe quelle boucle critique dans laquelle on cherche à tout sauf à mettre un wait.
Le
flush des WindowsEvent() se fait
intégralement (d'où la boucle),
le plus rapidement possible (comme n'importe quel bout de code), mais un nombre de fois limité.
Dans le code que j'ai donné ci dessus pour le jeu de SPH, cette boucle est exécutée sur appel d'une procédure qui n'est appelée que ponctuellement pour tester le clic souris (bidouillage, ok).
Dans le cadre d'un code monothreadé, on peut aussi l'appeler à chaque frame graphique, donc généralement 60x par secondes, "à peu prêt exactement" 0% de charge CPU.
Pour utiliser WaitWindowsEvent(), il faudra threader la chose afin de ne pas bloquer en l'absence d'événement. Sans doute le plus "pro", mais largement dispensable pour une appli simple. Perso, j'utilise beaucoup plus couramment la solution précédente.
Je réponds donc maintenant à vos remarques sur cette base:
lance ton code, et regarde le temp machine pris (control+alt+Del ) par ton prg ....
En fait mon code n'est pas vraiment lançable puisqu'il n'y a pas de boucle principale.
En pratique sur HexaScrabble pour lequel j'ai bidouillé cette procédure j'ai 19% de charge CPU, parce qu'il faut bien qu'HexaScrabble tourne.
La version originale de HexaScrabble qui utilises les fonctions natives de PB consomme les mêmes 19% de CPU (mais les souris Razer déconnent, bug PB).
Ma procédure n'engendre donc pas de charge supplémentaire.
Bref: 0%
Spock a écrit :
ensuite met un delay(2) ou WaitWindowsEvent(2) et regarde la difference
->avec delay(2), plus ma procédure est appelée souvent, plus la charge CPU baisse.... plus le temps disponible pour mon programme est faible, plus celui-ci devient lent.
Bref, j'obtiens un code peu performant avec une charge CPU proche de 0%.
->avec un WaitWindowsEvent(), le code arrête purement et simplement de s'exécuter tant que je ne touche pas ma souris. Pratique.
Spock a écrit :
pis parle français , j'ai pas compris ton "Et on flush"
"Vidange". Pourtant très courant dans le jargon de codeur...
Ollivier a écrit :
Le multi-tâche engendre des contraintes, notamment partager la main.
Les opérations GPU, un accès ram, disque, la synchro verticale (etc...) sont des moments où la main se rend naturellement. Au sein même du CPU certaines instructions chargeront plus ou moins le CPU. Au pire si notre application est extrêmement "CPU intensive" on baissera à peine la priorité de notre thread et on laissera l'Os faire. Bref, le multitasking, c'est son problème.
