Ce qui m'étonne c'est qu'on est obligé d'utiliser un Thread pour chaque objet graphique a actualiser / annimer.
Dans Qt que j'ai pas mal étudié, pour faire une barre de progression, une animation etc... on utilise l'objet QTimer.
Et QTimer n'utilise pas de Thread. C'est un objet pris en compte dans la boucle d'évenements QEventLoop de l'application. Cette boucle d'évenement, lorsqu'elle utilise l'appel système select() pour attendre les evenement de Xorg, doit prendre en compte les QTimers en ajoutant un timeout dans select. Ensuite avec le mécanisme de Signal/Slot de Qt, les slots d'objets liés au signal du QTimer sont alors appelés.
On fait donc avec Qt des objet animés (Barre de progression etc ...) sans qu'il n'y ai de Thread créés.
Dans Java Swing, il y'a l'air d'y avoir la même chose que sous Qt.
javax.swing.Timer :
"Fires one or more action events after a specified delay. For example, an animation object can use a Timer as the trigger for drawing its frames."
Mais dans l'API Java d'Android, Il n'y pas Swing.
Et pas d'autres objets Timer que Java.utils.Timer (Timer lié a un thread TimerTask).
Le problème est que en terme de performances ce n'est pas génial d'avoir plein de threads dans une application.
# Threads
Posté par ilip . En réponse au message Gestion d'un timer en Java/Android. Évalué à 0.
Ce qui m'étonne c'est qu'on est obligé d'utiliser un Thread pour chaque objet graphique a actualiser / annimer.
Dans Qt que j'ai pas mal étudié, pour faire une barre de progression, une animation etc... on utilise l'objet QTimer.
Et QTimer n'utilise pas de Thread. C'est un objet pris en compte dans la boucle d'évenements QEventLoop de l'application. Cette boucle d'évenement, lorsqu'elle utilise l'appel système select() pour attendre les evenement de Xorg, doit prendre en compte les QTimers en ajoutant un timeout dans select. Ensuite avec le mécanisme de Signal/Slot de Qt, les slots d'objets liés au signal du QTimer sont alors appelés.
On fait donc avec Qt des objet animés (Barre de progression etc ...) sans qu'il n'y ai de Thread créés.
Dans Java Swing, il y'a l'air d'y avoir la même chose que sous Qt.
javax.swing.Timer :
"Fires one or more action events after a specified delay. For example, an animation object can use a Timer as the trigger for drawing its frames."
Mais dans l'API Java d'Android, Il n'y pas Swing.
Et pas d'autres objets Timer que Java.utils.Timer (Timer lié a un thread TimerTask).
Le problème est que en terme de performances ce n'est pas génial d'avoir plein de threads dans une application.