cedricbi
Messages postés185Date d'inscriptionmercredi 18 décembre 2002StatutMembreDernière intervention21 mars 2011
-
3 août 2008 à 14:21
cedricbi
Messages postés185Date d'inscriptionmercredi 18 décembre 2002StatutMembreDernière intervention21 mars 2011
-
4 août 2008 à 16:21
Bonjour à tous,
Petite question pratique :
Dans un programme "bien codé", où doit (ou est générallement) géré l'affichage ? Dans un thread à part ou dans le thread principal (dans un timer, dans un évènement, dans une boucle infinie) ?
Par exemple, pour un programme qui affichage les cartes de Google Map, j'ai le thread principal qui ne fait... rien à part recevoir les évènements souris et les changements de paramètres, un thread d'affichage qui affiche les cartes voulues et un thread de téléchargement qui télécharge les cartes qui ne sont pas encore dans le cache. Cette solution marche mais j'ai des doutes quant au fait de mettre l'affichage dans un thread à part du thread principal.
<hr />Le plus dur dans un programme c'est de savoir pourquoi il marche !
A voir également:
Où gérer l'affichage dans une application classique ?
florenth
Messages postés1023Date d'inscriptiondimanche 1 août 2004StatutMembreDernière intervention17 août 20083 3 août 2008 à 15:15
Salut !
Normalement, la logique voudrait que toute la partie interaction avec l'utilisateur (clics clavier) et affichage (maj des édits/labels/statusbar, paint des paintbox, ...) se trouve dans le thread principal, mais pas de boucle infinie, Windows a déjà son système de messages et compagnie.
Et que toute la partie "traitement" (calcul, récupération de fichier via Internet, ...) se trouve dans un ou plusieurs threads séparés, qui se synchronisent régulièrement avec le thread principal pour signaler une mise à jour de l'affichage.
Bon, après, y'a des variantes, mais l'idée est là.
Dans ton cas, je ne vois pas comment ton thread séparé peut afficher les cartes voulues, logiquement seul le principal doit accéder à l'affichage (risque de corruption de la VCL sinon). Mais sinon, le reste est tout bon !
f0xi
Messages postés4205Date d'inscriptionsamedi 16 octobre 2004StatutModérateurDernière intervention12 mars 202235 4 août 2008 à 15:30
l'utilisation de thread dans une application est totalement facultatif, et doit être réservé a des choses bien spécifiques.
alors oui, comment determiner ou non, l'utilisation possible des threads ?
- quand l'application nécessite 2 temps distinct d'exécution, quand des données sont externes au programme, quand une action doit être indépendante etc. :
c'est le cas des logiciels de retouche d'image
c'est le cas des logiciels de montage video
c'est le cas des logiciels de composition audio
c'est le cas des logiciels p²p ou de telechargement
l'affichage et les interactions sont généralement dans le thread principal.
des threads secondaire peuvent etre créer pour la mise a jours d'element visuel (liste de donnée, image, flux etc)
par defaut, le thread principal est prioritaire sur les autres thread de l'application (sauf priorité ajustée).
par exemple, l'attente d'un Flux (audio, video, donnée brute), un calcul complexe, un telechargement peuvent etre threadés afin de ne pas freezer l'application ou le systeme.
cela permet par exemple d'ajuster la priorité du thread selon la charge CPU.
aucune action sur le systeme depuis X secondes -> priorité real time / haute
attention on touche a la souris ou au clavier -> priorité normale / basse
attention un autre programme comsome des ressources -> priorité normale / basse
c'est pour cela par exemple qu'une application bien codée (surtout sur les thread) ne freeze jamais ou rarement le systeme.
pour savoir dans quel evenement on doit gerer l'affichage, tout depend de l'affichage!
interface de composant standard (GDI, GDI+, OpenGL, DX) -> géré par l'appli et le systeme
interface personalisée sur un canvas (GDI, GDI+, OpenGL, DX) -> géré par un timer avec un RRt de 12 a 30 FPS (80 a 40ms) ou timer dédié a ce genre d'affichage. mais cela est facultatif puisqu'on peu gerer l'affichage dans la procedure Paint d'un TWinControl ou TGraphicControl etc.