Où gérer l'affichage dans une application classique ? [Résolu]

Messages postés
185
Date d'inscription
mercredi 18 décembre 2002
Dernière intervention
21 mars 2011
- - Dernière réponse : cedricbi
Messages postés
185
Date d'inscription
mercredi 18 décembre 2002
Dernière intervention
21 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 !
Afficher la suite 

Votre réponse

4 réponses

Meilleure réponse
Messages postés
1105
Date d'inscription
dimanche 1 août 2004
Dernière intervention
17 août 2008
3
Merci
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 !

A+
Florent

Ressources Delphi, sources, tutoriaux, actu, ...: www.mx-dev.net

Dire « Merci » 3

Quelques mots de remerciements seront grandement appréciés. Ajouter un commentaire

Codes Sources 97 internautes nous ont dit merci ce mois-ci

Commenter la réponse de florenth
Messages postés
4304
Date d'inscription
samedi 16 octobre 2004
Dernière intervention
9 mars 2018
3
Merci
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.

<hr size="2" width="100%" />

Dire « Merci » 3

Quelques mots de remerciements seront grandement appréciés. Ajouter un commentaire

Codes Sources 97 internautes nous ont dit merci ce mois-ci

Commenter la réponse de f0xi
Messages postés
185
Date d'inscription
mercredi 18 décembre 2002
Dernière intervention
21 mars 2011
0
Merci
Salut,

Dans le thread principal, évidement.. ! C'est ce que je pensais.
Mais maintenant, où dans le thread principal ? Sur quel évènement ?

Merci
Commenter la réponse de cedricbi
Messages postés
185
Date d'inscription
mercredi 18 décembre 2002
Dernière intervention
21 mars 2011
0
Merci
Bonjour,

Merci pour toutes ces précisions foxi !
Commenter la réponse de cedricbi

Vous n'êtes pas encore membre ?

inscrivez-vous, c'est gratuit et ça prend moins d'une minute !

Les membres obtiennent plus de réponses que les utilisateurs anonymes.

Le fait d'être membre vous permet d'avoir un suivi détaillé de vos demandes et codes sources.

Le fait d'être membre vous permet d'avoir des options supplémentaires.