Quand GDI + est sorti, je me souviens de tous les Brouhaha sur la façon dont c'était le moyen "nouveau, plus rapide" mieux "d'afficher des trucs dans Windows. Mais chaque fois que je l'ai regardé, il me semblait que c'était vraiment un wrapper com autour de GDI.
est-ce vrai? Ou GDI + est vraiment une bibliothèque graphique indépendante qui partage simplement certains paradigmes avec GDI?
Personnellement, je ne suis pas sûr de savoir comment cela pourrait être indépendant, mais je n'ai jamais vu une déclaration définitive d'une manière ou d'une autre.
3 Réponses :
GDI + est construit sur GDI et ajoute plusieurs autres fonctionnalités. Par exemple, GDI + ajoute la prise en charge de la transparence, de l'étirement bitmap anti-aliasing, etc.
GDI + est principalement une API à base d'objet, et GDI est une API de la fonction. La plupart des fonctionnalités de GDI + ne sont pas optimisées sur le matériel (il est manipulé par logiciel), contrastant avec GDI. Par exemple, dans GDI, BitBlt est géré directement par le matériel. Les fonctions de peinture GDI + bitmap ne sont pas.
GDI + est une API puissante, mais faites attention à ses performances.
GDI + est disponible en C ++, COM et .NET
gdi + n'est pas com. GDI + a une API "plate" sous-jacente appelée à partir de C (ou de toute autre langue, donc) et d'une enveloppe orientée objet en C ++ qui appelle simplement l'API plat. Il existe également des emballages dans .NET (System.Drawing) et Delphi qui appellent également l'API plat. Il fonctionne complètement différent de GDI en ce que vous ne définissez pas d'objets (stylos, pinceaux, polices) dans un contexte de périphérique, mais plutôt les transmettre à des fonctions de dessin. Il n'a pas beaucoup en commun avec GDI. Je ne sais pas si la mise en œuvre de GDI + utilise GDI - mais ce n'est probablement pas, car il a tant de fonctionnalités qui ne sont tout simplement pas disponibles dans GDI.
Malheureusement, il est plus lent que GDI. C'est très puissant cependant.
Comme DecastEljau a souligné entre-temps, les problèmes de performance pourraient provenir du fait qu'il n'est pas rendu dans du matériel, contrairement à OpenVG ou WPF. J'ai récemment utilisé Xna à cause de cela pour une application en temps réel graphique.
De nombreuses fonctions GDI sont accélérées par le matériel graphique et certaines routines GDI + peuvent utiliser GDI en dessous. Mais la majeure partie de GDI + est indépendante de GDI.
Un exemple important et qui raconte, est le rendu du texte. Dans GDI + Le rendu de texte est effectué complètement dans des logiciels; Les effets anti-aliasing, glyphe pixel et autres effets sont effectués sans la carte vidéo.
Chris Jackson de Microsoft a eu un post de blog intéressant où il a profilé le Différence de vitesse entre le rendu de texte dans GDI et GDI + :
... mon chemin de code GDI rendu
environ 99 000 glyphes par
Deuxièmement, alors que mon chemin de code GDI + était
Rendu environ 16 000 glyphes
par seconde.
Un autre exemple est le dessin de la ligne. GDI + prend en charge la ligne anti-aliasée / polygone et le dessin du cercle / ellipse, tandis que GDI ne le fait pas:
(Source: Microsoft.com )
.png)
(source: Microsoft.com )
(source: Microsoft.com )
(Source: Microsoft.com )
Mais pour répondre à votre question plus directement: GDI + est complètement nouveau. Cela devient effectivement un problème car il est plus lent que GDI (c'est-à-dire non accéléré), et le rendu de texte est différent de GDI (menant au texte qui peut sembler différent dans différentes parties d'une application .NET). Ce n'est pas un emballeur com autour de GDI, ce n'est même pas même com. C'est une API plate C. Microsoft a créé un ensemble de classes C ++ qui simplifient les fonctions plates. System.Drawing In .NET est un ensemble de classes qui appellent également les fonctions plates.
.png){kind=link}
.png){kind=link}