Jes suis depuis quelques temps ds la programmation Win32 en c/c++ et j'ai
une question sur les contexte de peripheriques à laquelle je n'ai pas trouvé
de reponse correcte sur gogle.
voici donc:
lorsque par exemple je prends un HDC dans WM_CREATE faut le supprimer avant
le retour à la boucle des messages ou la fermeture du programme.
Ex :
case WM_CREATE:
DC=GetDC(hWnd);
SetupPixelFormat(DC);
RC=wglCreateContext(DC);
wglMakeCurrent(DC, RC);
InitGL();
ReleaseDC(hWnd,DC);
break;
ou bien cet autre code serais plus efficace:
case WM_CREATE:
DC=GetDC(hWnd);
SetupPixelFormat(DC);
RC=wglCreateContext(DC);
if (!RC) SendMessage (hWnd,WM_CLOSE,0,0);
wglMakeCurrent(DC, RC);
InitGL();
break;
case WM_DESTROY:
wglMakeCurrent(NULL, NULL);
if (RC) wglDeleteContext(RC);
ReleaseDC(hWnd,DC);
PostQuitMessage(0);
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Christian ASTOR
heinquoi a écrit:
Jes suis depuis quelques temps ds la programmation Win32 en c/c++ et j'ai une question sur les contexte de peripheriques à laquelle je n'ai pas trouvé de reponse correcte sur gogle. voici donc: lorsque par exemple je prends un HDC dans WM_CREATE faut le supprimer avant le retour à la boucle des messages ou la fermeture du programme.
Il faut simplement le supprimer dès que l'on n'en a plus besoin. (ça consomme 1 objet GDI (nb limité, mais large), et la 16-bit GDI DGROUP de la 32-bit GDI heap sous 9x)
heinquoi a écrit:
Jes suis depuis quelques temps ds la programmation Win32 en c/c++ et j'ai
une question sur les contexte de peripheriques à laquelle je n'ai pas trouvé
de reponse correcte sur gogle.
voici donc:
lorsque par exemple je prends un HDC dans WM_CREATE faut le supprimer avant
le retour à la boucle des messages ou la fermeture du programme.
Il faut simplement le supprimer dès que l'on n'en a plus besoin.
(ça consomme 1 objet GDI (nb limité, mais large), et la 16-bit GDI
DGROUP de la 32-bit GDI heap sous 9x)
Jes suis depuis quelques temps ds la programmation Win32 en c/c++ et j'ai une question sur les contexte de peripheriques à laquelle je n'ai pas trouvé de reponse correcte sur gogle. voici donc: lorsque par exemple je prends un HDC dans WM_CREATE faut le supprimer avant le retour à la boucle des messages ou la fermeture du programme.
Il faut simplement le supprimer dès que l'on n'en a plus besoin. (ça consomme 1 objet GDI (nb limité, mais large), et la 16-bit GDI DGROUP de la 32-bit GDI heap sous 9x)
heinquoi
Cyrille Dupuydauby, m'a données ces infos sur le newsgroup microsoft:
Il y a 3 types de DCs associés à des fenêtres, le type dépend de la classe de fenêtre (ATTENTION, classe au sens Windows, pas C++) : - les privés : 1 DC par fenêtre de la classe. Rarement utilisé et cher, mais performant, car il n'est pas nécessaire de le reparamétrer à chaque utilisation. Cher parce chaque DC utilise 1,5% de la mémoire reservée au GDI. - de classe : 1 DC pour toutes les fenêtres de la classe. Pratique pour les fenêtres types contrôles qui se dessinent toutes à l'identique. - parent : le DC associé à la fenêtre est celui de la fenêtre parent. C'est le style utilisé pour les contrôles systèmes. - commun : le DC provient d'un lot commun de 5 DCs (par thread théoriquement). Cas pour les fenêtres standards et les boîtes de dialogue.
La doc MS n'est pas clair sur le sujet, mais explique qu'il ne faut pas vérouiller abusivement les DCs communs sous peines de poser des problèmes aux autres applications (au moins sous Windows 95/98/Me).
Ma conclusion est : par défaut, il ne faut pas conserver le DC au delà du traitement d'un message (ton cas 1). Si on veut absolument maximiser les performances, il faut déclarer sa classe de fenêtre (avec AfxRegisterClass) avec le style CS_OWNDC, a CONDITION de ne pas ouvrir trop de fenêtre de ce type. Dans l'idéal, travailler en mode classique (DC partagé) le temps de la mise au point et passé au mode optimisé une fois cela terminé.
Cyrille Dupuydauby
Cyrille Dupuydauby, m'a données ces infos sur le newsgroup microsoft:
Il y a 3 types de DCs associés à des fenêtres, le type dépend de la classe
de fenêtre (ATTENTION, classe au sens Windows, pas C++) :
- les privés : 1 DC par fenêtre de la classe. Rarement utilisé et cher, mais
performant, car il n'est pas nécessaire de le reparamétrer à chaque
utilisation. Cher parce chaque DC utilise 1,5% de la mémoire reservée au
GDI.
- de classe : 1 DC pour toutes les fenêtres de la classe. Pratique pour les
fenêtres types contrôles qui se dessinent toutes à l'identique.
- parent : le DC associé à la fenêtre est celui de la fenêtre parent. C'est
le style utilisé pour les contrôles systèmes.
- commun : le DC provient d'un lot commun de 5 DCs (par thread
théoriquement). Cas pour les fenêtres standards et les boîtes de dialogue.
La doc MS n'est pas clair sur le sujet, mais explique qu'il ne faut pas
vérouiller abusivement les DCs communs sous peines de poser des problèmes
aux autres applications (au moins sous Windows 95/98/Me).
Ma conclusion est : par défaut, il ne faut pas conserver le DC au delà du
traitement d'un message (ton cas 1). Si on veut absolument maximiser les
performances, il faut déclarer sa classe de fenêtre
(avec AfxRegisterClass) avec le style CS_OWNDC, a CONDITION de ne pas ouvrir
trop de fenêtre de ce type.
Dans l'idéal, travailler en mode classique (DC partagé) le temps de la mise
au point et passé au mode optimisé une fois cela terminé.
Cyrille Dupuydauby, m'a données ces infos sur le newsgroup microsoft:
Il y a 3 types de DCs associés à des fenêtres, le type dépend de la classe de fenêtre (ATTENTION, classe au sens Windows, pas C++) : - les privés : 1 DC par fenêtre de la classe. Rarement utilisé et cher, mais performant, car il n'est pas nécessaire de le reparamétrer à chaque utilisation. Cher parce chaque DC utilise 1,5% de la mémoire reservée au GDI. - de classe : 1 DC pour toutes les fenêtres de la classe. Pratique pour les fenêtres types contrôles qui se dessinent toutes à l'identique. - parent : le DC associé à la fenêtre est celui de la fenêtre parent. C'est le style utilisé pour les contrôles systèmes. - commun : le DC provient d'un lot commun de 5 DCs (par thread théoriquement). Cas pour les fenêtres standards et les boîtes de dialogue.
La doc MS n'est pas clair sur le sujet, mais explique qu'il ne faut pas vérouiller abusivement les DCs communs sous peines de poser des problèmes aux autres applications (au moins sous Windows 95/98/Me).
Ma conclusion est : par défaut, il ne faut pas conserver le DC au delà du traitement d'un message (ton cas 1). Si on veut absolument maximiser les performances, il faut déclarer sa classe de fenêtre (avec AfxRegisterClass) avec le style CS_OWNDC, a CONDITION de ne pas ouvrir trop de fenêtre de ce type. Dans l'idéal, travailler en mode classique (DC partagé) le temps de la mise au point et passé au mode optimisé une fois cela terminé.
Cyrille Dupuydauby
Christian ASTOR
heinquoi a écrit:
Cyrille Dupuydauby, m'a données ces infos sur le newsgroup microsoft:
Oui, je lis aussi ms...vc. C'est la doc MSDN : http://msdn.microsoft.com/library/default.asp?url=/library/en-us/gdi/devcons_3r77.asp Et c'est pas bien de faire du multi-post...
heinquoi a écrit:
Cyrille Dupuydauby, m'a données ces infos sur le newsgroup microsoft:
Oui, je lis aussi ms...vc.
C'est la doc MSDN :
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/gdi/devcons_3r77.asp
Et c'est pas bien de faire du multi-post...
Cyrille Dupuydauby, m'a données ces infos sur le newsgroup microsoft:
Oui, je lis aussi ms...vc. C'est la doc MSDN : http://msdn.microsoft.com/library/default.asp?url=/library/en-us/gdi/devcons_3r77.asp Et c'est pas bien de faire du multi-post...
heinquoi
"Christian ASTOR" a écrit dans le message de news:40977df6$0$316$
heinquoi a écrit:
> Cyrille Dupuydauby, m'a données ces infos sur le newsgroup microsoft:
C'est vrai c'est pas bien mais malheureusement lorsque les newsgroups sont moue, c'est le meilleur moyen que j'ai trouvé d'avoir une réponse surtout si la question est au croisement de newsgroup ( programmation c++, programmation windows)
"Christian ASTOR" <castorix@club-internet.fr> a écrit dans le message de
news:40977df6$0$316$7a628cd7@news.club-internet.fr...
heinquoi a écrit:
> Cyrille Dupuydauby, m'a données ces infos sur le newsgroup microsoft:
C'est vrai c'est pas bien mais malheureusement lorsque les newsgroups sont
moue, c'est le meilleur moyen que j'ai trouvé d'avoir une réponse surtout si
la question est au croisement de newsgroup ( programmation c++,
programmation windows)
C'est vrai c'est pas bien mais malheureusement lorsque les newsgroups sont moue, c'est le meilleur moyen que j'ai trouvé d'avoir une réponse surtout si la question est au croisement de newsgroup ( programmation c++, programmation windows)
Cyrille Szymanski
On 2004-05-04, heinquoi <nospam* wrote:
Et c'est pas bien de faire du multi-post...
C'est vrai c'est pas bien mais malheureusement lorsque les newsgroups sont moue, c'est le meilleur moyen que j'ai trouvé d'avoir une réponse surtout si la question est au croisement de newsgroup ( programmation c++, programmation windows)
Dans ce cas x-post. Quoi qu'il en soit, innonder les ng pour obtenir plus de visibilité peut marcher à court terme mais c'est *très* mal vu. Les habitués sauront beaucoup mieux que toi te rediriger vers le bon groupe (fu2 adéquat) s'ils estiment que tu auras des réponses plus pertinentes ailleurs.
-- cns
On 2004-05-04, heinquoi <nospam*heinquoi1@libertysurf.fr> wrote:
Et c'est pas bien de faire du multi-post...
C'est vrai c'est pas bien mais malheureusement lorsque les newsgroups sont
moue, c'est le meilleur moyen que j'ai trouvé d'avoir une réponse surtout si
la question est au croisement de newsgroup ( programmation c++,
programmation windows)
Dans ce cas x-post. Quoi qu'il en soit, innonder les ng pour obtenir
plus de visibilité peut marcher à court terme mais c'est *très* mal
vu. Les habitués sauront beaucoup mieux que toi te rediriger vers le
bon groupe (fu2 adéquat) s'ils estiment que tu auras des réponses plus
pertinentes ailleurs.
C'est vrai c'est pas bien mais malheureusement lorsque les newsgroups sont moue, c'est le meilleur moyen que j'ai trouvé d'avoir une réponse surtout si la question est au croisement de newsgroup ( programmation c++, programmation windows)
Dans ce cas x-post. Quoi qu'il en soit, innonder les ng pour obtenir plus de visibilité peut marcher à court terme mais c'est *très* mal vu. Les habitués sauront beaucoup mieux que toi te rediriger vers le bon groupe (fu2 adéquat) s'ils estiment que tu auras des réponses plus pertinentes ailleurs.
