Discussion :

[Yuna]

Bonjour � tous,
je vais commencer par d�tailler mon contexte visual C++/ MFC et ensuite vous exposez mon probl�me. Je vais faire mon maximum pour �tre claire

Je travaille sur un prototype d'application avec une fen�tre de type CWnd/OpenGL dans une architecture CWinApp / CMainFrame classique, sans SDI ou MDI (donc pas d'objet d�riv� de CView).
Cette application assure �galement de la reconnaissance de geste (effectu� avec un bras � retour d'effort) et cette reconnaissance de geste est assur� � la fr�quence graphique puisqu' effectu�e dans le thread graphique.

Je veux lancer l'impression de ma fen�tre CWnd/OpenGL apr�s avoir effectu� un geste pr�cis reconnu dans mon thread graphique.
J'ai d�cid� pour cela d'utiliser le couple

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

PostMessage(AfxGetMainWnd()->m_hWnd ,WM_PRINT_GEO,0,0)/ ON_MESSAGE(WM_PRINT_GEO,OnPrint)

avec un define de WM_PRINT_GEO � partir WM_USER.

Je veux donc depuis mon thread graphique, appeler la fonction d'impression impl�ment� dans le CMainFrame.

Ca "marchouille" mais j'ai des rendus bizarres d'impression, la fen�tre (ou active area de ma CWnd pour �tre pr�cise) OpenGL imprim�e est assez al�atoire avec parfois les dessins du geste assurant l'impression ou alors un cadre noir ou une portion d'�cran noir au lieu d'�tre blanc......
En fait, je pense que le fait de poster un message pour le run windows depuis le thread graphique perturbe le thread graphique et j'imprime un r�sultat assez al�atoire.

Qu'en pensez-vous?
Puis-je proc�der autrement pour lancer l'impression de ma fen�tre qu'avec un PostMessage?

En vous remerciant par avance pour vos suggestions,
bonne journ�e.

[bacelar]

Par "le thread graphique", veux-tu parler du thread cr�� au d�marrage de l'application et ayant une file de message et une pompe � message MFC ?

Si oui, Le PostMessage ne fait que reporter l'appel � la fonction de callback car PostMessage met le message dans la file de message du thread ayant cr�� la fen�tre. Donc dans notre cas c'est "le thread graphique" qui ex�cutera "OnPrint", quand le message sera d�pil� de la file de message donc bien plus tard.

Si ton application n'est pas en cours de finalisation, je te conseillerais de dissoci� le rendu graphique, lourd et mollement temps r�el, de la reconnaissance de forme qui devrait, je pense, avoir des conditions temps r�el plus dures. En clair, d�tection de mouvement dans un thread � part et d�di� et communication asynchrone avec le thread graphique via PostMessage, par exemple.

Des mes lointains souvenirs OpenGL, c'est une architecture Client/Server et comme ton appel � "OnPrint" est compl�tement d�synchronis� de la fin de restitution de la sc�ne, je ne vois pas comment tu peux avoir quelque chose de correcte. Ne doit-on pas attendre un �v�nement pour �tre sur que le rendu de la sc�ne est fini, ou la wglu planque tout cela ?

[Yuna]

Re-bonjour � tous!

Bon, j'ai r�solu mon probl�me seule comme une grande! Ca change.....
Apr�s analyse de ce qui se passait effectivement, j'ai compris que c'�tait la barre des t�ches windows qui venait se mettre au-dessus de la zone active client OpenGL de la fen�tre de mon application lors de l'impression, c'est sans doute li� � l'ic�ne de l'imprimante qui apparait, bref.
R�sultat : j'avais des trucs bizarres au bas de l'impression.

Pour cacher pendant la dur�e de l'application cette barre des t�ches windows:
- dans le COGLViewApp::InitInstance() :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
//*****************HIDE_TASK_BAR*******************/
HWND hTask = ::FindWindow(_T("Shell_TrayWnd"), _T(""));
::ShowWindow(hTask, SW_HIDE);
//***************************************************/

- dans le COGLViewApp::ExitInstance()

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
//*****************SHOW_TASK_BAR*******************/
HWND hTask = ::FindWindow(_T("Shell_TrayWnd"), _T(""));
::ShowWindow(hTask, SW_SHOW);
//***************************************************/

Et pour conclure, un

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

PostMessage(AfxGetMainWnd()->m_hWnd ,WM_PRINT_GEO,0,0)/ ON_MESSAGE(WM_PRINT_GEO,OnPrint)

depuis un thread graphique vers le CFrameWnd ne pose aucun probl�me, tout est okay.

Bonne journ�e � tous.

[Yuna]

Par "le thread graphique", veux-tu parler du thread cr�� au d�marrage de l'application et ayant une file de message et une pompe � message MFC ?

Si oui, Le PostMessage ne fait que reporter l'appel � la fonction de callback car PostMessage met le message dans la file de message du thread ayant cr�� la fen�tre. Donc dans notre cas c'est "le thread graphique" qui ex�cutera "OnPrint", quand le message sera d�pil� de la file de message donc bien plus tard.

Si ton application n'est pas en cours de finalisation, je te conseillerais de dissoci� le rendu graphique, lourd et mollement temps r�el, de la reconnaissance de forme qui devrait, je pense, avoir des conditions temps r�el plus dures. En clair, d�tection de mouvement dans un thread � part et d�di� et communication asynchrone avec le thread graphique via PostMessage, par exemple.

Des mes lointains souvenirs OpenGL, c'est une architecture Client/Server et comme ton appel � "OnPrint" est compl�tement d�synchronis� de la fin de restitution de la sc�ne, je ne vois pas comment tu peux avoir quelque chose de correcte. Ne doit-on pas attendre un �v�nement pour �tre sur que le rendu de la sc�ne est fini, ou la wglu planque tout cela ?

Zut, j'ai post� en m�me temps que toi, du coup j'ai r�pondu sans avoir lu tes propos Bacelar, je suis d�sol�e.
Mon thread graphique est g�r� au niveau du RenderScene() OpenGL par l'interm�diaire d'un objet Scene et j'instancie cet objet Scene dans l'initInstance () de la CWinApp.
Et ma client area OpenGL est cr��e dans le CMainFrame:

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
// create a view to occupy the client area of the frame
if (!m_wndView.Create(NULL, NULL, AFX_WS_DEFAULT_VIEW,
CRect(0, 0, 0, 0), this, AFX_IDW_PANE_FIRST, NULL))
{
	TRACE0("Failed to create view window\n");
	return -1;
}

Pour le coup, je poste bien le message au CMainFrame qui appelle ma fonction d'impression. J'imprime la scene � l'instant t.

Pour l'application elle-m�me, elle reste un prototype de R&D, je l'ai r�cup�r� en l'�tat; le jour o� ce prototype doit �tre d�velopp� sous forme de vrai logiciel, beaucoup de choses seront reprises, notamment au niveau des threads graphique, haptique et sans doute un nouveau d�di� � la reconnaissance de geste, effectivement. Un gros boulot de conception avant quoi

Merci encore pour tes suggestions.