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

cedricbi 185 Messages postés mercredi 18 décembre 2002Date d'inscription 21 mars 2011 Dernière intervention - 3 août 2008 à 14:21 - Dernière réponse : cedricbi 185 Messages postés mercredi 18 décembre 2002Date d'inscription 21 mars 2011 Dernière intervention
- 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
florenth 1105 Messages postés dimanche 1 août 2004Date d'inscription 17 août 2008 Dernière intervention - 3 août 2008 à 15:15
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

Merci florenth 3

Avec quelques mots c'est encore mieux Ajouter un commentaire

Codes Sources a aidé 120 internautes ce mois-ci

Commenter la réponse de florenth
Meilleure réponse
f0xi 4304 Messages postés samedi 16 octobre 2004Date d'inscription 9 mars 2018 Dernière intervention - 4 août 2008 à 15:30
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%" />

Merci f0xi 3

Avec quelques mots c'est encore mieux Ajouter un commentaire

Codes Sources a aidé 120 internautes ce mois-ci

Commenter la réponse de f0xi
cedricbi 185 Messages postés mercredi 18 décembre 2002Date d'inscription 21 mars 2011 Dernière intervention - 3 août 2008 à 16:40
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
cedricbi 185 Messages postés mercredi 18 décembre 2002Date d'inscription 21 mars 2011 Dernière intervention - 4 août 2008 à 16:21
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.