Version imprimable
Bonjour à tous.
Je voudrai savoir comment gérer le double buffering avec l'API Windows.
Créer deux memory device contexts et les copier l'un après l'autre sur le display device context avec BitBlt fait presque du double buffering, puisque cela donne le même rendu, mais en plus lent, non?
En effet, c'est sans doute plus lent.
Mais je ne crois pas qu'on puisse faire mieux en GDI...
DirectX, par contre, peut surement faire du "vrai" double-buffering.
Rien ne t'empêche de faire l'essai...on dit que le GDI est lent mais bien utilisé cela peut donner des résultats satisfaisants..Citation:
Envoyé par _Michel
Si les performances ne sont pas satisfaisantes oui alors utiliser l'accélération matérielle avec Direct X.
Tout dépend de ce que tu veux faire...si c'est juste quelques animations le GDI peut parfois suffire
Pour le double buffering pourquoi ne pas utiliser WGL ? Renseigne-toi sur la structure PIXELFORMATDESCRIPTOR et la fonction SwapBuffers.
En fait ce sont les fonctions de dessin (Rectangle, Ellipse, etc.) de la GDI qui sont lentes, pas la GDI elle-même (l'affichage OpenGL sous Windows utilise la GDI ...). Mais t'as raison, bien utilisée, cette API peut faire des choses presque incroyables.Citation:
Envoyé par Mat.M
Oui, c'est pour une application qui n'a pas besoin de grosses machines come OpenGL ou DirectX.
Mais pour ma culture, pourquoi on à pas acces à l'accéleration matérielle ni aux buffers avec GDI?
En parlant de rapidité, avec quelles fonction peut-on acceder rapidement au bitmap?
Je suppose qu'il n'y a rien de plus rapide que l'acces direct à la mémoire et je suppose qu'il n'y a rien de plus lent que SetPixel.
En effet.
Déjà, SetPixelV() est plus rapide, mais si tu veux vraiment de la vitesse, utilise un DIB (Device-Independent Bitmap), que tu peux obtenir avec le bon paramètre de LoadImage(), ou créer à partir de rien avec la fonction CreateDIBSection().
Avec un DIB, tu disposes d'un accès direct à la mémoire des pixels du bitmap.
Pour l'accélération matérielle, parce que la GDI est une API de haut niveau qui se veut d'être indépendante du matériel alors qu'OpenGL par exemple est une interface de programmation vers la carte graphique. Même raisons pour le double buffering (pas de double buffers avec une imprimante par exemple ...).Citation:
Envoyé par _Michel
Médinoc t'as déjà répondu mais pour ajouter à ce qu'il a dit, bien exploiter les régions valides / invalides permet aussi d'améliorer considérablement la vitesse. Le principe c'est que pour actualiser un dessin, il suffit d'invalider le plus petit rectangle contenant la zone à redessiner et lors du traitement de WM_PAINT, utiliser le handle retourné par BeginPaint car ce handle ne permet de dessiner que dans le rectangle qui fut invalide.Citation:
Envoyé par _Michel
Quant à SetPixel(V), c'est lent lorsqu'elle est utilisée en boucle car elle n'est pas optimisée, alors que les autres fonctions de dessin utilisent en quelque sorte un SetPixel optimisé. Ne serait-ce que le coût d'un appel de fonction, ça pénalise déjà le programme ...
Ok merci. Juste une dernièrequestion : quand on selectionne un bitmap dans un DC cela ne l'affiche pas et on ne peut rien faire avec. Pourtant si on le selectionne dans un memory DC, là on peut utiliser les fonctions du GDI.
Comment ça se fait? C'est dans la nature des DC?
On ne peut sélectionner un bitmap que sur un DC en mémoire (lire la doc de SelectObject).
:mur:
Merci beaucoup.
Je te conseille de consulter la doc de Direct X ; tu y trouveras un schéma qui t'expliques cela..Citation:
Envoyé par _Michel
pour faire simple Direct X "shunte" ou bien appelle en parallèle au GDI les fonctionnalités de la carte graphique..
sinon basiquement pourquoi le GDI n'appelle pas l'accélération matérielle c'est une bonne question...
parce que au début Windows n'était pas prévu pour faire de la 3d et il n'y avait pas de cartes avec puce 3d..
et comme le dit Melem le GDI est plus haut niveau...
Direct X a été crée par Microsoft pour un accès direct à la VRAM ou mem vidéo..
pour les premières versions de Direct X tu n'avais que DirectDraw tu n'avais pas de 3d et tu faisais comme en assembleur à accéder à la mémoire vidéo pour afficher des pixels....
et puis Microsoft veut maintenir une compatibilité ascendante, je crois qu'il ya un verrou win16 dans le GDI qui t'empêche de faire des graphismes performants
Oui, il parait que win32 est condamné à devenir du passé (dommage, ça marche bien pourtant, mieux que cette daube de .NET etc etc).
Pour la doc du sdk, j'ai pas trouvé, mais c'est pas grave, je compte m'y mettre un jour et voir ça de près.
Qui a dit cela que win32 va devenir du passé ?? M'étonnerait, avec VC++2008 il ya même une nouvelle version pour les MFCCitation:
Envoyé par _Michel
:D
Pour Direct X il faut télécharger le SDK
C'est pas moi qui l'ai dit mais tu devineras mon pressentiment là dessus :mouarf: :aie:Citation:
mieux que cette daube de .NET