DirectX avec les MFC

Je ne m'adressais pas forcement a toi :)
mais je voulais dissiper le semblant
de FUD que pouvait soulever ton
"N'y a-t-il pas un probleme vis-a-vis des librairies graphiques en multi-threading"
 
A+
LEGREG

 
Ah ben non ! Le OnDraw est appelé à chaque fois qu'il y a à redessiner la fenêtre (resize, minimisation/maximisation, perte de focus, fenêtre qui passe devant etc...)  mais si il n'y a rien à faire, la méthode n'est pas appelée (encore heureux sinon on réinvente le monotache :))

[edtdd]--Message édité par n0mad--[/edtdd]

 
mais... OnDraw() d'une CView, t sur qu'elle est pas appelée régulièrement, sans qu'il y ai à faire quoi que ce soit !? (invalidateRect ou autre...)

 
Bon OK faut que je sois super clair :D,  
tu n'as pas compris ma critique: il ne s'agit pas de dire qu'un thread ou un timer ne permet pas de faire la tache mais
ton affirmation qu'un evenement "WM_IDLE" etait poste de maniere erratique et donc entrainait un affichage du meme acabit etait errone et la doc effectivement te contredit: il n'y a pas d'evenement WM_IDLE.
Demande a ElGringo comment il aurait fait s'il n'avait pas utilise les MFC's et bien il aurait fait comme avec OnIdle:
il aurait traite les messages comme ils arrivent et la plupart du temps il l'aurait passe dans une fonction qui se charge de mettre a jour son monde.
L'avantage des threads c'est que tu ne dois pas penser "temps reel" lorsque tu programmes parce que tu as un scheduler qui s'en charge de repartir le temps processeur pour toi mais en contrepartie tu la paies en temps de debuguage et de pose des verrous (qui peut aussi creer des blocages).
 
Je n'ai pas trouve ta citation sur la page en lien par contre j'ai trouve ca :D :
Threads
When you need a background task, threads may not be your best solution. Effective idle handling of the event may be a better solution. It?s easier to understand the locality of reference of your program with one thread than with two or more.
 
A good rule of thumb is that you should only use a thread if an operating system notification that you need to block on is at the root of the background work. Threads are best in such a case because it is not practical to block a main thread on an event.
 
Threads also present communication problems. You will have to manage the communication link between your threads, whether it be with a list of messages or by allocating and using shared memory. Managing your communication link will likely require synchronization to avoid race conditions and deadlock problems. Such complexity can easily turn into  bugs and performance problems.
 
Ce qui resume ce que je viens de dire en quelques dizaines de posts.
 
A+
LEGREG
Ps: si je programmais en java j'utiliserais
des threads. Mais tu n'as pas plus de garanties sur la stabilite
des frames en java qu'en C++ avec MFC, ONIDLE et threads..
La seule garantie que tu peux avoir c'est quand tu auras tout fait dans ta maniere de programmer (ca peut etre lourd suivant tes contraintes par exemples sur les acces reseau par internet ou autre) pour que l'affichage soit le plus smooth possible mais parfois la seule solution c'est de revenir a du tres bas niveau (Play station2 par ex).

[edtdd]--Message édité par legreg--[/edtdd]

je peux t'en sortir un autre :
 
"OnIdle function   Idle events can occur at times you do not expect, such as between WM_KEYDOWN and WM_KEYUP events. Timers may be a more efficient way to trigger your desired behavior. Also, you should not force OnIdle to be called repetitively by generating false messages or by always returning TRUE from an override of OnIdle because this will never allow your thread to sleep. Again, a timer or a separate thread might be more appropriate. "
 
http://msdn.microsoft.com/library/ [...] l_code.asp
 
par "un peu n'importe quand", j'entends que l'envoi du onidle dépend de facteurs qui ne permettent pas un framerate stable. c'est tout :)

 
Ton interpretation de la doc me semble bizarre
 
Voici le vrai extrait MSDN:
 
Run cycles through a message loop, checking the message queue for available messages. If a message is available, Run dispatches it for action. If no messages are available ? often the case ? Run calls OnIdle to do any idle-time processing that you or the framework may need done. If there are no messages and no idle processing to do, the application waits until something happens. When the application terminates, Run calls ExitInstance. The figure The Message Loop in OnIdle Member Function shows the sequence of actions in the message loop.
 
A+
LEGREG

je ne connais pas CView ... mais c'est une classe qui encapsule une fenêtre, non ? :D tu as une fenêtre ... tu as une classe que tu peux dériver ... dx ne demande qu'un hwnd pour être initialisé ... où est le problème ? où es tu bloqué ?

 
à mon avis, ton argument qui te fais me déconseiller le OnIdle est bon, en tout cas, g aucun mal à le croire... c pas fait pour ça le OnIdle. Faire un autre thread, ça m'parait trop compliqué. Alors maintenant (ouais, je sais, je suis tétu :D), si qqn peut me dire qqch sur: comment afficher un rendu D3D dans une CView, je suis prenneur...

 
Nope il n'y a pas de problemes... Si tu geres ca bien :).
Exemple de mauvaise gestion:
un thread balance des polygones tandis qu'un deuxieme
alloue des textures.. Resultat non garanti.
Exemple de bonne gestion:
Un thread se charge de gerer les acces reseau (c'est ce que
fait DirectPlay, si je ne m'abuse) ou de jouer la musique et les effets sonores, un autre de l'affichage.
Pour limiter les effets d'acces concurrent a la memoire et aux ressources, tu ne permets qu'a un type de thread d'acceder a un type de ressource et tu bases ton appli sur un modele client- serveur(une thread qui gere la logique du jeu est client d'un serveur qui gere l'affichage).
Pour ce qui est de l'acces au variables partagees, il faut toujours les proteger par mutex meme si tu n'as pas encore eu de problemes ca ne veut pas dire qu'il n'y en aura pas
(tu pars du principe que certaines actions sont atomiques alors
qu'elles ne le sont pas). Eventuellement pour une gestion plus fine tu implantes un Read/Write Lock ou les autres modeles.. cf cours de programmation systeme pour plus de details.
 
MAIS
C'est beaucoup se compliquer la vie, en general  
reprogrammer la boucle de gestion des evenements
(ou le OnIdle si tu n'y a pas acces) suffit amplement pour une appli temps reel simple.
 
LEGREG

et pourquoi donc ? ça permet d'avoir la gui qui répond tout le temps, le rendu qui ne bloque rien. pour prendre un parallèle connu, c'est ce qui se passe dans photoshop : tu as une thread gui, et une thread qui calcule les effets (genre gaussian blur) et qui balance le résultat à la thread gui pour qu'elle update les fenêtres.

 
de gérer avec OnIdle ou avec un thread, sans vouloir vs vexer, ça m'parait pas un peu du bricolage. En fait c parce que g lu un truc sur internet. ils rentraient pas dans les détails, mais ils disaient que pour utiliser DirectX avec les MFC, ils disaient d'afficher le rendu D3C dans une CViewForm. enfin, je pense que dans une CView quelconque, ça peut fonctionner pareil. Et en fait, c plutot ça qui m'interresse (à défaut de ça, je garde qd même le "OnIdle" en tête, mulit-threading--> trop complex pour si peut)

N'y a-t-il pas un probleme vis-a-vis des librairies graphiques en multi-threading ? En generales celles-ci doivent etre utilisees uniquement depuis la thread principale, non ?

Un thread c'est une solution
mais ce n'est pas la seule  
et puis se pose le probleme de la gestion
des acces concurrents a la memoire:
ajouter des mutex et verrous.
et surtout si tu utilises les librairies
de thread tu n'as pas trop de controle sur le scheduler
(temps passe a faire des calculs et de l'affichage).
Comme l'a deja ete dit pour la troisieme fois:
Overrider OnIdle dans la CWinApp c'est une solution
simple, la gestion du temps dans ce cas peut etre simple rassure toi. (consiste a calculer le temps ecoule depuis le dernier trace par exemple)
 
LEGREG

 
Parce que j'en ai jammais fait, que ça m'fait un peu peur. Et que g tjs entendu dire que le multi threading est lourd à gérer, donc à éviter autant que possible... c faux !?

[edtdd]--Message édité par z51--[/edtdd]

 
Sisi ca marche
 
LEGREG

le plus simple : pourquoi ne fais-tu pas une thread qui s'occupe de tout le temps rafraîchir ta fenêtre ?

[edtdd]--Message édité par El_Gringo--[/edtdd]

 
Pff tu me prends pour un neuneu ou quoi?
je sais tres bien pourquoi TU veux qu'il la retrace
je te disais juste que windows ne le fera pas parce
que c'est un besoin specifique a TON application.
 
La solution (puisqu'en encapsulant tu as perdu
l'acces a ton wndproc), c'est de passer soit
par le timer (ca peut etre genant: quel valeur mettre au timer?? je crois que tres peu de jeux fonctionnent comme ca.. c'est aussi vrai qu'ils n'utilisent pas les MFC pour le moteur du jeu lui-meme. mais MFC est souvent utilise pour les outils)
Soit de provoquer le retracage dans la partie OnIdle de ton CWinApp. (mais il faudra passer par une gestion du temps, si tu veux avoir une animation fluide et reguliere quoiqu'il arrive)
 

 
Attends! il y a incompatibilite et incompatibilite.
Il y a de nombreuses personnes qui utilisent les MFC
avec toutes sortes de choses et des gens qui y sont
allergiques. ca peut etre une incompatibilite de personne
ou un probleme religieux (mais DX = microsoft aussi).
Pour les performances, la perte des MFC c'est principalement
au niveau memoire et taille de l'appli
(l'encapsulation a un cout), pour l'affichage, tu ne vas
pas utiliser les widgets standards et GDI pour ton appli temps reel de la mort qui tue.. enfin c'est toi qui vois.
 
A+
LEGREG

 
Un timer, c une bonne idée, mais j'aurai aucune idée du Delay à mettre... c qd même un truc primordial la fréquence à laquelle est appelé le truc. Et puis ça fait un peu bricolo, non !?:D

 
Je voudrais qu'il retrace automatiquement ma fenêtre windows parce que pour des animations, y faut bien qu'y retrace régulièrement, même si il a pas reçu de message spécifique... y retrace tt le temps, c tout ! Dans beaucoup de cas, le contenu des frames est redessiné régulièrement. ça bouffe pas tout le temps processus... y a un truc dans les OS multi process (ma fois, plutot répandus aujourd'hui :D) qui s'appel le partage du temps processeur, c génial, et ça te permet de redessiner régulièrement une fenêtre en faisant d'autre trucs en même temps, génial non ?:D
 
sinon, le truc qui pourrait faire que les MFC soient déconseillées pour DirectX, c que DirectX à besoin d'un maximum de ressources. Si les MFC ne ralentissent qu'un petit peu, c pas gênant pr apprendre, ms après ça peut le devenir (au moment ou on en est à écrire des bout de code en ASM pour gagner un peu de ressources) les MFC "gachent" forcément un peu de ressources... mais es ce à un degré perceptible !? j'en sais rien du tout !

 
Et pourquoi tu voudrais qu'il la retrace automatiquement ta fenetre, windows?
La plupart des fenetres windows (arf, no pun intended)  n'ont pas besoin d'etre retracees tout le temps sinon ton proc serait en permanence occupe a 100% et ton ordi ramerait comme pas possible. Si tu veux la retracer c'est a toi de le faire.
 
Sinon aucun pb a utiliser dx avec les mfc, je vois pas pourquoi il y en aurait (sachant que MFC c'est juste une encapsulation orientee objet de l'API windows)
 
A+
LEGREG

[edtdd]--Message édité par El_Gringo--[/edtdd]