Zeph (./29) :
Je rejoins 0² contre les "while (se_passe_t_il_qqchose())", surtout quand comme ici les threads pourraient se permettre d'être en pause une grande majorité du temps (même dans un jeu, on martèle rarement les touches toutes les quelques millisecondes). Si le coût pour continuer à utiliser GetMessage c'est d'avoir une pauvre queue asynchrone pour transférer les messages à l'unique thread GUI, alors ça me semble être quand même raisonnable niveau quantité de code.

Heu… Je n'ai pas l'impression que tu comprennes comment ça doit fonctionner…
Y'a des trucs que tu peux pas faire sur le thread de rendu pendant que certains se passent sur le thread d'interface, et vice-versa, y'a aucune histoire de passage de message ou autre…
Le thread UI *est* celui qui reçoit les messages de Windows (et pas l'inverse comme tu l'as écrit), c'est lui qui va éventuellement les foutre dans une file asynchrone qui sera lue par le thread de physique / mise à jour (qui n'a rien à voir avec le rendu !).

Et justement pourquoi avoir deux threads quand tu peux simplement faire…

Tant que exécution en cours
Si message reçu => Traiter message
Sinon => Rendu graphique

C'est plutôt simple. On effectue le rendu à vitesse maximum, et on fait une petite pause pour gérer les messages si jamais il y a besoin. Pas besoin de faire attention à ce qui peut être manipulé dans un cas où dans l'autre puisque les deux ne se produisent jamais en même temps…

Mais bon, il y a un réel avantage à ça, mais à vous lire j'ai vraiment l'impression que vous êtes à côté de la plaque… Justement, l'intérêt d'utiliser une boucle parallèle avec GetMessage, ce n'est pas de "faire moins" comme vous semblez argumentez, mais bien au contraire, de "faire plus"…

Pourquoi cela ?

1 - Parce que que quand la gestion des messages (négligeable) est entrelacée avec le rendu, certains messages vont bloquer le rendu : Affichage d'un menu en mode fenêtré, redimensionnement de la fenêtre, affichage d'une boîte de dialogue modale, etc.
Ce n'est certainement pas un mal, et il y a un paquet de scénarios dans lequel c'est préférable… Et un paquet de scénarios dans lequel ça l'est moins, ou pas du tout.
(Quoi qu'il en soit c'est bien pour un PC pas puissant parce que la lourdeur du processus de rendu ne ralentira pas l'interface graphique.)

2 - Parce que quand le système de rendu tourne normalement (pas mis en pause par un cas du 1)), il peut arriver qu'il bouffe trop de temps CPU et que les messages soient traités trop peu souvent… Ce qui produira de l'input lag si mal géré… (Je pense que tout le monde a déjà du avoir ce problème un jour avec certains jeux, genre au pif Counter Strike )

Donc l'intérêt, ce n'est pas que le thread "ne branle rien"… C'est justement qu'il puisse faire quelque chose tout le temps, et à n'importe quel moment… Beaucoup de jeux apprécieront de recevoir les messages "en temps réel", et beaucoup de lecteurs multimédias apprécieront de voir la vidéo continuer à tourner pendant qu'un menu ou une boite de dialogue se sera ouverte…*
Mais beaucoup d'applications n'auront pas besoin de voir la zone de rendu s'animer pendant ouverture des menus, et ne consommeront pas suffisamment de puissance CPU pour le rendu au point de nécessiter d'avoir une boucle séparée du rendu…

Ce qui compte, c'est d'utiliser au mieux les ressources dont tu disposes, pas de demander deux fois plus de ressources pour en faire deux fois moins…

* Cela étant dit, il est tout à fait possible d'avoir un rendu continu effectué par le thread UI alors même que des évènements bloquants se produisent…