Vergleich von Direct2D und GDI-Hardwarebeschleunigung

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

Dieses Thema besteht aus den folgenden Teilen:

Unterschiede zwischen Direct2D und GDI

GDI rendert nicht transparente Geometrien mit Alias, z. B. Polygone, Ellipsen und Linien. Sie rendert Alias- und ClearType-Text und kann die Transparenzmischung über die AlphaBlend-API unterstützen. Die Handhabung der 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 GDI-Rendering nicht einfach 3D-Vorgängen zuteil wird, und eine moderne GPU wird auf dem 3D-Teil der Rendering-Engine am effektivsten gerendert. Beispielsweise sind die Aliaslinien von Direct2Dso 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, aliasbasierte und Antialiasing-Primitive. Moderne Beis nutzen häufig Transparenz und Animation. Direct2D erleichtert die Erstellung einer modernen Benutzeroberfläche, da sie strenge Garantien dafür bietet, wie transparente Inhalte akzeptiert und gerendert werden und alle primitiven Elemente mithilfe der Hardwarebeschleunigung gerendert werden. Direct2D ist keine reine Obermenge von GDI:Primitive, die bei der Umsetzung auf einer GPU unverhältnismäßig 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, das dann seine Entsprechung im Kernelmodus aufruft, die die Primitiven an ihr eigenes Treibermodell übergibt. Dieser Treiber sendet die Ergebnisse dann an den Anzeigetreiber für den globalen Kernelmodus.

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

Abbildung 1 – direct2d im Vergleich zu gdi

GDI- und Direct2D-Hardwarebeschleunigung

Der wichtigste Unterschied zwischen Direct2D und GDI-Hardwarebeschleunigung ist die zugrunde liegende Technologie, die sie steuert. Direct2D befindet sich auf direct3D,und GDI verfügt über ein eigenes Treibermodell, die GDI Device Driver Interface (DDI), die den GDI-Primitiven entspricht. Das Direct3D-Treibermodell entspricht dem, was die 3D-Renderinghardware in einer GPU rendert. Als die GDI-DDI zum ersten Mal definiert wurde, wurden die meisten Hardwarekomponenten für die Anzeigebeschleunigung auf die GDI-Primitive ausgerichtet. Im Laufe der Zeit lag der Schwerpunkt immer mehr auf der Beschleunigung von 3D-Spielen und weniger auf der Anwendungsbeschleunigung. Infolgedessen wurde die BitBlt-API hardwarebeschleunigt, und die meisten anderen GDI-Vorgänge waren dies nicht.

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

Abbildung 2: Entwicklung des GDI-Anzeigerenderings

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

Erhöhen der Komplexität und Größe von Anzeigetreibern

3D-Treiber sind im Laufe der Zeit komplexer geworden. Komplexerer Code hat in der Regel mehr Fehler, was es vorteilhaft macht, dass der Treiber im Benutzermodus vorhanden ist, bei 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 beim Synchronisieren von Sitzungs- und globalen Kerneladressenräumen

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

Verwaltung zusammengesetzter Fenster

Der Desktopfenster-Manager (DWM), der in Windows 7 eingeführte Zusammenstellungsfenster-Manager, rendert alle Fenster auf Off-Screen-Oberflächen und erstellt sie dann zusammen, um sie auf dem Bildschirm anzuzeigen. Dies erfordert, dass GDI auf einer Oberfläche gerendert werden kann, die dann von Direct3D zur Anzeige gerendert wird. Dadurch wurde ein Problem im XP-Treibermodell behoben, da GDI und Direct3D parallele Treiberstapel waren.

Daher wurde in Windows Vista der GDI-DDI-Anzeigetreiber als der von Microsoft bereitgestellte Canonical Display Driver (CDD) implementiert, der GDI-Inhalt in eine Systemspeicherbitmap renderte, die auf dem Bildschirm zusammengesetzt werden soll.

GDI-Rendering in Windows 7

Das in Windows Vista verwendete Treibermodell erforderte, dass jedes GDI-Fenster sowohl durch eine Videospeicheroberfläche als auch durch eine 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 ein Aperture-Speichersegment gerendert wird. Der Öffnungsspeicher kann von der Videospeicheroberfläche mit dem Fensterinhalt aktualisiert werden. GDI kann wieder in den Öffnungsspeicher gerendert werden, und das Ergebnis kann dann zurück an die Fensteroberfläche gesendet werden. Da das Aperture-Speichersegment von der GPU adressiert werden kann, kann die GPU diese Aktualisierungen der Videospeicheroberfläche beschleunigen. Beispielsweise werden text rendering, BitBlts, AlphaBlend, TransparentBlt und StretchBlt in diesen Fällen beschleunigt.

Gegenüber gegenüber der Direct2D- und GDI-Beschleunigung in Windows 7

Direct2D und GDI sind beide 2D-Rendering-APIs im unmittelbaren Modus und werden hardwarebeschleunigt. Es gibt jedoch eine Reihe von Unterschieden, die in beiden APIs bestehen bleiben.

Speicherort der Ressourcen

GDI verwaltet seine Ressourcen, insbesondere Bitmaps, standardmäßig im Systemspeicher. Direct2D verwaltet seine Ressourcen im Videospeicher auf dem Adapter. Wenn GDI den Videospeicher aktualisieren muss, muss dies über den Bus erfolgen, es sei denn, die Ressource befindet sich bereits im Aperture-Speichersegment oder der Vorgang kann direkt ausgedrückt werden. Im Gegensatz dazu kann Direct2D einfach seine Primitive in Direct3D-Primitive ü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 aus, um den Arbeitsspeicher mithilfe der CPU zu vergrößern. Im Gegensatz dazu übersetzt Direct2D seine APIs-Aufrufe in Direct3D-Primitive und Zeichnungsvorgänge. Das Ergebnis wird dann auf der GPU gerendert. Ein Teil des GDI-Renderings wird auf der GPU ausgeführt, wenn der Öffnungsspeicher auf die Videospeicheroberfläche kopiert wird, die das GDI-Fenster darstellt.

Skalierbarkeit

Die Renderingaufrufe von Direct2Dsind alle unabhängige 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 Buildup von GPU- und CPU-Renderingkontextaufwand führen.

Standort

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. GDIverfügt jedoch über einen Großteil seiner Funktionalität im Sitzungsraum im Kernelmodus, dessen API-Oberfläche sich im Benutzermodus befindet.

Verfügbarkeit der Hardwarebeschleunigung

GDI wird auf Windows XP hardwarebeschleunigt und auf Windows 7 beschleunigt, wenn die Desktopfenster-Manager ausgeführt wird und ein WDDM 1.1-Treiber verwendet wird. Direct2D wird auf fast jedem WDDM-Treiber hardwarebeschleunigt und gibt an, ob DWM verwendet wird. 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 Clippingbereiche angewendet werden, um sicherzustellen, dass eine Anwendung nicht außerhalb ihres Fensters gerendert wurde. Im Direct2D-Modell wird eine Anwendung in einem Backpuffer gerendert, und das Ergebnis wird angezeigt, wenn die Anwendung mit dem Zeichnen fertig ist. Dadurch kann Direct2D Animationsszenarien viel flexibler verarbeiten als GDI.

Zusammenfassung

Der vorhandene GDI-Code funktioniert unter Windows 7 weiterhin gut. Beim Schreiben von neuem Grafikrenderingcode sollte Direct2D jedoch berücksichtigt werden, da moderne GPUs besser genutzt werden.