Vergleich von Direct2D und GDI-Hardwarebeschleunigung

Direct2D und GDI sind beide 2D-Rendering-APIs im direkten Modus und bieten ein gewisses Maß an Hardwarebeschleunigung. In diesem Thema werden die Unterschiede zwischen Direct2D und GDI untersucht, einschließlich früherer und gegenwärtiger Unterschiede in den Hardwarebeschleunigungsfunktionen beider APIs.

Dieses Thema umfasst die folgenden Teile:

• Unterschiede zwischen Direct2D und GDI
• GDI- und Direct2D-Hardwarebeschleunigung
  • Zunehmende Komplexität und Größe von Anzeigetreibern
  • Schwierigkeiten bei der Synchronisierung von Sitzungs- und globalen Kerneladressräumen
  • Verwaltung zusammengesetzter Fenster
• GDI-Rendering in Windows 7
• Gegenüberstellung der Direct2D- und GDI-Beschleunigung in Windows 7
  • Speicherort von Ressourcen
  • Renderingmethode
  • Skalierbarkeit
  • Location
  • Verfügbarkeit der Hardwarebeschleunigung
  • Präsentationsmodell
• Zusammenfassung

Unterschiede zwischen Direct2D und GDI

GDI rendert undurchsichtige Aliasgeometrien wie Polygone, Ellipsen und Linien. Es rendert Alias- und ClearType-Text und kann die Transparenzmischung über die AlphaBlend-API unterstützen. Der Umgang mit Transparenz ist jedoch inkonsistent, und die meisten GDI-APIs ignorieren einfach den Alphakanal. Wenige GDI-APIs garantieren, was der Alphakanal nach einem Vorgang enthält. Noch wichtiger ist, dass das Rendering von GDI nicht einfach 3D-Vorgängen zugeordnet wird, und eine moderne GPU rendert am effizientesten im 3D-Teil der Rendering-Engine. Beispielsweise sind die Aliaslinien von Direct2D so konzipiert, dass sie einfach als zwei Dreiecke implementiert werden, die auf der GPU gerendert werden, während GDI den Linienzeichnungsalgorithmus von Bresenham verwendet.

Direct2D rendert undurchsichtige, transparente, aliasierte und antialiasierte Grundtypen. Moderne UIs nutzen häufig Transparenz und Animation. Direct2D erleichtert das Erstellen einer modernen Benutzeroberfläche, da es strenge Garantien dafür bietet, wie transparente Inhalte akzeptiert und gerendert werden, und alle seine Grundtypen werden mithilfe der Hardwarebeschleunigung gerendert. Direct2D ist keine reine Obermenge von GDI: Primitive, die bei der Implementierung auf einer GPU unangemessen langsam gewesen wären, sind in Direct2D nicht vorhanden. Da Direct2D mit diesem Schwerpunkt auf der 3D-Beschleunigung erstellt wird, ist es auch einfach mit Direct3D zu verwenden.

Seit Windows NT 4 wird GDI im Kernelmodus ausgeführt. Die Anwendung ruft GDI auf, die dann ihre Kernelmodus-Entsprechung aufruft, die die Grundtypen an ihr eigenes Treibermodell übergibt. Dieser Treiber sendet dann die Ergebnisse an den Anzeigetreiber für den globalen Kernelmodus.

Ab Windows 2000 werden GDI und die GDI-Treiber in einem unabhängigen Bereich im Kernel namens "Sitzungsraum" ausgeführt. Für jede Anmeldesitzung wird ein Sitzungsadressraum erstellt, und jede instance von GDI wird unabhängig in diesem unterschiedlichen Kernelmodus-Adressraum ausgeführt. Direct2D wird jedoch im Benutzermodus ausgeführt und übergibt Zeichnungsbefehle über den Direct3D-Treiber des Benutzermodus an den Kernelmodustreiber.

GDI- und Direct2D-Hardwarebeschleunigung

Der wichtigste Unterschied zwischen Direct2D- und GDI-Hardwarebeschleunigung ist die zugrunde liegende Technologie, die sie antreibt. Direct2D ist auf Direct3D übereinander angeordnet, und GDI verfügt über ein eigenes Treibermodell, die GDI Device Driver Interface (DDI), die den GDI-Grundtypen entspricht. Das Direct3D-Treibermodell entspricht dem, was die 3D-Renderinghardware in einer GPU rendert. Als GDI DDI zum ersten Mal definiert wurde, richtete sich die meiste Hardware für die Anzeigebeschleunigung auf die GDI-Grundtypen. Im Laufe der Zeit wurde immer mehr Wert auf die Beschleunigung von 3D-Spielen und weniger auf die Anwendungsbeschleunigung gelegt. Infolgedessen wurde die BitBlt-API hardwarebeschleunigt und die meisten anderen GDI-Vorgänge nicht.

Dadurch wird die Phase für eine Abfolge von Änderungen an der Darstellung von GDI festgelegt. Die folgende Abbildung zeigt, wie sich das GDI-Anzeigerendering von Windows XP zu Windows 7 geändert hat.

Es gab auch eine Reihe zusätzlicher Faktoren, die Änderungen am GDI-Treibermodell verursacht haben, wie unten erläutert.

Zunehmende Komplexität und Größe von Anzeigetreibern

3D-Treiber sind im Laufe der Zeit komplexer geworden. Komplexerer Code hat tendenziell mehr Fehler, was es für den Treiber vorteilhaft macht, im Benutzermodus zu existieren, in dem ein Treiberfehler keinen Systemneustart verursachen kann. Wie in der obigen Abbildung zu sehen ist, ist der Anzeigetreiber in eine komplexe Benutzermoduskomponente und eine einfachere Kernelmoduskomponente unterteilt.

Schwierigkeiten bei der Synchronisierung von Sitzungs- und globalen Kerneladressräumen

In Windows XP ist ein Anzeigetreiber in zwei verschiedenen Adressräumen vorhanden: Sitzungsraum und Kernelbereich. Teile des Treibers müssen auf Ereignisse wie Energieverwaltungsereignisse reagieren. Dies muss mit dem Treiberzustand im Sitzungsadressraum synchronisiert werden. Dies ist eine schwierige Aufgabe und kann zu Fehlern führen, wenn Anzeigetreiber versuchen, mit diesen unterschiedlichen Adressräumen umzugehen.

Verwaltung zusammengesetzter Fenster

Der Desktopfenster-Manager (DWM), der in Windows 7 eingeführte Fenster-Manager, rendert alle Fenster auf Off-Screen-Oberflächen und erstellt sie dann zusammen, um sie auf dem Bildschirm anzuzeigen. Dies erfordert , dass GDI in der Lage ist, auf einer Oberfläche zu rendern, die dann von Direct3D gerendert wird, um anzuzeigen. Dies stellte ein Problem im XP-Treibermodell dar, da GDI und Direct3D parallele Treiberstapel waren.

Daher wurde in Windows Vista der GDI DDI-Anzeigetreiber als von Microsoft bereitgestellter canonical Display Driver (CDD) implementiert, der GDI-Inhalte in eine Bitmap des Systemspeichers gerendert hat, die auf dem Bildschirm zusammengesetzt werden soll.

GDI-Rendering in Windows 7

Das in Windows Vista verwendete Treibermodell erforderte, dass jedes GDI-Fenster sowohl von einer Videospeicheroberfläche als auch von einer Systemspeicheroberfläche unterstützt wird. Dies führte dazu, dass der Systemspeicher für jedes GDI-Fenster verwendet wurde.

Aus diesem Grund wurde GDI in Windows 7 erneut geändert. Anstatt auf eine Systemspeicheroberfläche zu rendern, wurde GDI so geändert, dass es in einem Blendenspeichersegment gerendert wird. Der Blendenspeicher kann über die Videospeicheroberfläche aktualisiert werden, auf der sich der Inhalt des Fensters befindet. GDI kann zurück in den Blendenspeicher gerendert werden, und das Ergebnis kann dann an die Fensteroberfläche zurückgesendet werden. Da das Aperture-Speichersegment von der GPU adressiert werden kann, kann die GPU diese Updates auf der Videospeicheroberfläche beschleunigen. Beispielsweise werden text rendering, BitBlts, AlphaBlend, TransparentBlt und StretchBlt in diesen Fällen beschleunigt.

Gegenüberstellung der Direct2D- und GDI-Beschleunigung in Windows 7

Direct2D und GDI sind sowohl 2D-Rendering-APIs im direkten Modus als auch hardwarebeschleunigt. Es gibt jedoch eine Reihe von Unterschieden, die in beiden APIs bestehen.

Speicherort von Ressourcen

GDI verwaltet seine Ressourcen, insbesondere Bitmaps, standardmäßig im Systemspeicher. Direct2D verwaltet seine Ressourcen im Videospeicher auf der Grafikkarte. Wenn GDI den Videospeicher aktualisieren muss, muss dies über den Bus erfolgen, es sei denn, die Ressource befindet sich bereits im Blendenspeichersegment oder wenn der Vorgang direkt ausgedrückt werden kann. Im Gegensatz dazu kann Direct2D seine Grundtypen einfach in Direct3D-Grundtypen übersetzen, da sich die Ressourcen bereits im Videospeicher befinden.

Renderingmethode

Um die Kompatibilität zu gewährleisten, führt GDI einen großen Teil seines Renderings im Blendenspeicher mithilfe der CPU aus. Im Gegensatz dazu übersetzt Direct2D seine APIs-Aufrufe in Direct3D-Grundtypen und Zeichnungsvorgänge. Das Ergebnis wird dann auf der GPU gerendert. Ein Teil des Renderings von GDI wird auf der GPU ausgeführt, wenn der Blendenspeicher auf die Videospeicheroberfläche kopiert wird, die das GDI-Fenster darstellt.

Skalierbarkeit

Die Renderingaufrufe von Direct2D sind alle unabhängigen Befehlsstreams an die GPU. Jede Direct2D-Factory stellt ein anderes Direct3D-Gerät dar. GDI verwendet einen Befehlsstream für alle Anwendungen im System. Die GDI-Methode kann zu einem Aufbau des GPU- und CPU-Renderingkontextaufwands führen.

Position

Direct2D funktioniert vollständig im Benutzermodus, einschließlich der Direct3D-Laufzeit und des Direct3D-Treibers im Benutzermodus. Dadurch können Systemabstürze verhindert werden, die durch Codefehler im Kernel verursacht werden. GDI verfügt jedoch über den größten Teil seiner Funktionalität im Sitzungsbereich im Kernelmodus, mit seiner API-Oberfläche im Benutzermodus.

Verfügbarkeit der Hardwarebeschleunigung

GDI wird unter Windows XP hardwarebeschleunigt und unter Windows 7 beschleunigt, wenn der Desktopfenster-Manager ausgeführt wird und ein WDDM 1.1-Treiber verwendet wird. Direct2D ist hardwarebeschleunigt auf fast jedem WDDM-Treiber und unabhängig davon, ob DWM verwendet wird oder nicht. Unter Vista wird GDI immer auf der CPU gerendert.

Präsentationsmodell

Als Windows zum ersten Mal entworfen wurde, war nicht genügend Arbeitsspeicher vorhanden, damit jedes Fenster in einer eigenen Bitmap gespeichert werden konnte. Daher wird GDI immer logisch direkt auf dem Bildschirm gerendert, wobei verschiedene Beschneidungsbereiche angewendet werden, um sicherzustellen, dass eine Anwendung nicht außerhalb ihres Fensters gerendert wurde. Im Direct2D-Modell wird eine Anwendung in einem Rückpuffer gerendert, und das Ergebnis wird angezeigt, wenn das Zeichnen der Anwendung abgeschlossen ist. Dadurch kann Direct2D Animationsszenarien viel flüssiger verarbeiten als GDI.

Zusammenfassung

Vorhandener GDI-Code funktioniert unter Windows 7 weiterhin gut. Wenn Sie jedoch neuen Grafikrenderingcode schreiben, sollte Direct2D in Betracht gezogen werden, da moderne GPUs besser genutzt werden.