Réponse acceptée !
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.