Bei der Entwicklung von XP zu Vista ist Windows die Hardwarebeschleunigung für 2D-Grafiken abhanden gekommen. Mit Windows 7 kehrt sie nun zurück. ZDNet erläutert die Hintergründe und zeigt, was vom neuen Direct2D zu erwarten ist.
Microsoft hat eine Angewohnheit, auf die man sich zu 100 Prozent verlassen kann: Features von aktuellen Programmversionen werden von der Marketingabteilung in höchsten Tönen gelobt. Sobald jedoch die Nachfolgeversion ein einigermaßen stabiles Entwicklungsstadium erreicht hat, gibt man sich in Redmond alle Mühe, dieselben Features möglichst schlecht zu reden.
Ein Beispiel dafür sind die Remote Desktop Services. Zu Zeiten von XP und Windows 2003 waren Microsoft-Sicherheitsexperten damit beschäftigt, zu erläutern, wie sicher und unknackbar die Verschlüsselung ist. Ein Terminalzugang über das Internet sei völlig ohne jedes Risiko. Als jedoch die Beta von Vista erschien, verstummten die Verschlüsselungsspezialisten plötzlich.
Versuchte man nämlich, sich mit dem Remote-Desktop-Client der Vista-Beta an einen XP- oder Windows-2003-Rechner zu verbinden, dann erschien eine auffällige Warnung, dass man schnell den Cancel-Button drücken solle, da das alte RDP5-Protokoll viel zu unsicher sei. Das ist auch in den finalen Versionen von Vista und Windows Server 2008 so geblieben.
Offensichtlich soll das "Mobbing" von alten Versionen dazu dienen, die Benutzer zu motivieren, Updates auf die aktuelle Version zu kaufen. Bei Windows Vista hat das allerdings nicht funktioniert. Selbst nach Aufrüstung des Hauptspeichers und Anschaffung der teuersten Grafikkarte mit Video-RAM von mehreren Gigabyte bleibt das subjektive Gefühl von langsamen Reaktionszeiten auf Mausbefehle.
Es wurde viel über die Gründe der Trägheit von Windows Vista spekuliert. Jede Menge Tipps und Tricks empfahlen das Ausschalten der zahlreichen sinnlosen oder zweifelhaften Dienste wie Superfetch und Readyboost. Genutzt hat das aber alles nichts.
Der Hauptgrund ist nämlich so naheliegend, dass niemand darauf gekommen ist. Vista ist schlicht und einfach nicht in der Lage, 2D-Grafiken mit geeigneten Grafikkarten zu beschleunigen. Nach dem RTM von Windows 7 gibt Microsoft das gemäß seinen Gepflogenheiten offen zu[1]. Das mag unglaubwürdig klingen, entspricht aber sowohl den Tatsachen als auch der leicht nachzuvollziehenden Beobachtung, dass Windows XP und Windows 7 auf Benutzereingaben schnell reagieren, während sich Vista äußerst antwortschwach zeigt.
Bildergalerie
Microsofts Probleme mit 2D-Grafik[2]
» zur Bildergalerie ...[2]
Bild 1: 2-D-Grafik gibt es in einer fensterbasierenden Benutzeroberfläche nicht.
In einem fensterorientierten System wie Windows gibt es keine Zweidimensionalität. Zwar besteht jedes einzelne Fenster nur aus einer X- und einer Y-Achse, jedoch besitzt der Desktop eine Z-Komponente, die immer dann relevant wird, wenn sich zwei Fenster überlappen. Obwohl der Abstand auf der Z-Achse 0 beträgt, ist es entscheidend, in welcher Reihenfolge die Fenster auf der Z-Achse angeordnet sind. Daher spricht man von der Z-Order, siehe Bild 1[3] und Bild 2[4].
Dieses virtuelle Koordinatensystem nennt man auch 2,5-dimensional. Dieser Begriff ist allerdings noch mit weiteren Bedeutungen[5] belegt. Obwohl das Koordinatensystem "flach" ist, muss man eine dritte Dimension einbeziehen. Echte Zweidimensionalität gibt es nur bei Fullscreen-Anwendungen.
Bild 2: Dieses Bild zeigt dieselben Fenster wie in Bild 1. Nur die "Z-Order" wurde vertauscht.
Bei Grafikkarten ohne jede Hardwarebeschleunigung, etwa Standard-VGA- oder ältere SVGA-Karten, stellt sich die Frage, wie man 2,5D-Fenster auf dem 2D-Bildschirm darstellt. Das linke Fenster in Bild 1 stellt einen Vollkreis dar. Da das Fenster jedoch von einem anderen zur Hälfte überlappt wird, darf nur ein Halbkreis gezeichnet werden.
Die einfachste Lösung wäre, zunächst das "unterste" Fenster komplett zu zeichnen. Danach zeichnet man nacheinander die darüberliegenden Fenster. Das ist aber überhaupt nicht praktikabel, da jede noch so kleine Änderung im sichtbaren Teils eines Fenster dazu führen würde, dass das der gesamte Desktop neu aufgebaut werden müsste.
Bild 3: Windows 1.0 kam 1985 ohne überlappende Fenster auf den Markt.
Man muss also eine andere Lösung finden, die nur den sichtbaren Teil eines Fenster zeichnet. Gleichzeitig muss gewährleistet sein, dass das API für den Programmierer so gestaltet ist, dass er einfach nur einen Kreis zeichnen kann, ohne sich darum zu kümmern, ob und wie viel von seinem Fenster sichtbar ist.
Microsoft ist an dieser Herausforderung zunächst gescheitert. Als im Jahr 1985 Windows 1.0 mit großer Verspätung erschien, unterstützte es keine überlappenden Fenster, siehe Bild 3[6].
Zwar konnte Windows 1.0 Dialogboxen und Menüs über andere Fenster legen, aber nur, weil die Fenster darunter eingefroren wurden. Ansonsten war es lediglich möglich, den Bildschirm in einzelne Rechtecksegmente aufzuteilen.
Bild 4: Digital Research beherrschte überlappende Fenster mit GEM (Quelle: Wikipedia).
Andere Hersteller beherrschten damals überlappende Fenster, beispielsweise Digital Research mit GEM[7], siehe Bild 4[8]. Erst 1987 konnte Microsoft mit Windows 2.0 überlappende Fenster anbieten.
Bis dahin musste Steve Ballmer, damals Vice President für Sales und Marketing, persönlich sein ganzes Verkaufstalent[9] einsetzen, damit Windows nicht durch GEM vollends vom Markt verdrängt wird.
Um nicht von GEM verdrängt zu werden, musste Steve Ballmer für Windows 1.0 persönlich sein ganzes Verkaufstalent einsetzen (Quelle: YouTube).
Die Technologie hinter überlappenden Fenster ist eigentlich recht simpel. Immer wenn ein Teil eines ganz oder teilweisen verdeckten Fensters sichtbar wird, erhält es die Nachricht WM_PAINT. Die Parameter der Nachricht beschreiben das Rechteck, das zusätzlich sichtbar geworden ist. Die Anwendung, der das Fenster gehört, muss auf diese Nachricht reagieren und mindestens diesen Ausschnitt neu zeichnen. Oft zeichnen die Anwendungen jedoch ihr ganzes Fenster neu oder mindestens ganze Objekte wie einen Kreis, sofern sie innerhalb des Rechtecks liegen.
Darüber hinaus können Clipping-Technologien[10] von Windows verwendet werden, die verhindern, dass über die Fenstergrenzen hinaus gezeichnet wird. Ihre Nutzung ist optional. Ein Programmierer kann über eine Einstellung auf Clipping verzichten und muss dann selbst dafür sorgen, dass er die Fenstergrenzen einhält. Dafür erhält er eine höhere Ausführungsgeschwindigkeit der Grafik-APIs.
Unter 2D-Beschleunigung einer Grafikkarte versteht man häufig nur die Fähigkeit einer Grafikkarte, zweidimensionale Objekte, wie Linien, Polygone, Kreise und Kurven selbst zeichnen zu können, ohne dass die CPU alle Pixel selbst berechnen muss. So können unter anderem auch skalierbare Vektorfonts wie TrueType[11] oder OpenType[12] von der Grafikkarte in jeder Größe selbst gerendert werden.
Das ist aber nur ein Teil der 2D-Beschleunigung. Eine wesentliche Beschleunigung lässt sich durch moderne Grafikkarten erzielen, die in der Lage sind 2,5D-Layer[13] hardwaremäßig zu erzeugen. Dabei werden auch die nicht sichtbaren Teile eines Fensters in einem virtuellen Rechteck, das jeweils ein komplettes Fenster repräsentiert, an die Grafikkarte übergeben und dort komplett gerendert. Die Grafikkarte kennt Größe und Position der virtuellen Rechtecke und über den Z-Buffer[14] teilt man der Karte mit, in welcher Z-Order die Fenster angezeigt werden müssen.
Bild 5: Ohne 3D-Beschleunigung kommt Expression Web mit dem Abarbeiten der WM_PAINT-Nachrichten nicht hinterher.
Mit reinen 2D-Beschleunigerkarten funktioniert das nicht. Z-Buffering zählt zu den 3D-Technologien. Der Vorteil ist, dass ein Fenster immer komplett gerendert werden kann. Wenn man Fenster verschiebt, muss einer Windows-Anwendung keine WM_PAINT-Message geschickt werden, um sichtbar gewordene Teile eines Fensters neu zu zeichnen.
Microsoft hat diese Technologie erstmals mit Windows Vista implementiert. Sie ist nur bei Verwendung der Aero-Oberfläche aktiv. Das erklärt, warum man für die Aero-Oberfläche eine 3D-Grafikkarte benötigt, auch wenn man keine 3D-Grafiken verwendet. Die Vorteile des Hardware-Layerings kann man unter Vista und Windows 7 leicht beobachten. Besonders gut geht das mit einer Anwendung, die etwas träge reagiert.
ZDNet wählt dazu den Microsoft-HTML-Editor, der beispielsweise in Expression Web oder Visual Studio integriert ist. Der ist bei komplexen Webseiten so langsam, dass man schneller tippen kann, als die Webseite aktualisiert wird. Bild 5[15] zeigt zwei Fenster von Expression Web. Im oberen wird der HTML-Quelltext dargestellt, das untere sollte die fertige Webseite anzeigen.
Bild 6: Mit der Aero-Oberfläche, die Z-Buffering nutzt, lässt sich der Internet Explorer problemlos über Expression Web ziehen.
Zieht man nun eine beliebiges Fenster, etwa den Internet-Explorer, von links nach rechts über Expression Web, dann sieht man die Spuren in Bild 5 im unteren Fenster. Das obere Fenster mit dem HTML-Sourcecode ist kaum betroffen, da Windows die WM_PAINT-Nachrichten recht fix abarbeiten kann. Im Prinzip kann man die Spuren beim Ziehen eines Fensters mit jeder Anwendung nachvollziehen, allerdings nicht in so einer extremen Ausprägung wie bei Expression Web.
Dieser Effekt ist in den Themes Vista Basic oder Windows Standard sichtbar. Bild 6[16] zeigt, dass dieses Phänomen bei der Aero-Oberfläche nicht auftritt. Durch die 2,5D-Beschleunigung muss Expression Web seine Fenster nicht neu rendern, wenn man ein anderes darüber zieht.
Da sich 3D-Grafikkarten bereits seit Mitte der 90er Jahre durchgesetzt haben, ist die Unterstützung von Hardware-Layern mehr als überfällig gewesen. Das Layering bereitete Microsoft jedoch einige Probleme, die im Endeffekt dazu führten, dass in Vista eine halbherzige Implementierung abgeliefert wurde.
Über die Jahre haben sich mehrere APIs etabliert, die Zugriff auf die Fenster in Windows erhalten. Die ursprüngliche Schnittstelle, die noch aus Windows 1.0 stammt, ist das GDI[17]. Damit lassen sich einfache 2D-Grafiken zeichnen. Heute kommen vor allem DirectX-Technologien[18] wie DirectDraw[19] und Direct 3D[20] hinzu.
Die Schwierigkeit dabei besteht in der Koexistenz der verschiedenen APIs. Das ist eine durchaus komplexe Aufgabe. Schon oft hat Microsoft dabei etwas geschummelt. Das gilt zum Beispiel für den GDI-Nachfolger GDI+[21]. GDI ist ein reines Standard-C-Interface. Programmcode von komplexen Anwendungen, der GDI verwendet, ist sehr schwer zu lesen. Neue Entwickler, die sich in ein Projekt einarbeiten müssen, haben Mühe, sich durch bestehenden Code zu arbeiten.
GDI+ ist ein C++-Interface, dass mehr Funktionen bietet und auch gut von .NET-Anwendungen genutzt werden kann. Vergleichbar ist GDI+ mit der Quartz2D-Schnittstelle[22] von Mac OS X.
GDI+ ist seit Windows NT4 Service Pack 4 verfügbar. Entwickler müssen also nicht befürchten, dass GDI+-Anwendungen nur unter den neuesten Windows-Versionen laufen. Allerdings ist GDI+ bis Windows XP als "Huckepack-API" auf GDI implementiert. So konnte Microsoft das Problem umgehen, dass die APIs GDI und GDI+ konkurrierend auf Windows-Fenster zugreifen.
Der negative Effekt ist allerdings, dass GDI+ in dieser Implementierung sehr performanceschwach ist. Chris Jackson[23] stellte anhand eines einfachen Quick-and-dirty-Benchmarks fest, dass GDI+ etwa um den Faktor sechs langsamer ist. Derartige Werte motivieren Entwickler kaum, GDI+ zu verwenden. Hinzu kommt, dass sich Altanwendungen nicht so einfach portieren lassen.
Bild 7: Die Grafik (rote Balken) zeigt den immensen Speicherverbrauch des DWM unter Vista (Quelle Microsoft).
Mit Vista hat Microsoft bezüglich GDI+ durchaus Fortschritte erzielt. ZDNet konnte mit dem Chris-Jackson-Benchmark eine GDI+-Performance von 92,4 Prozent messen bezogen auf die Geschwindigkeit von GDI. Allerdings hat Microsoft erneut geschummelt. Mit Vista hat Microsoft den Desktop Window Manager (DWM) eingeführt. Der sollte als Teil des Windows Display Driver Model eine Schicht zwischen Fenster und Treiber bilden und die Zugriffe verschiedener APIs auf die Fenster koordinieren.
Dabei hat Microsoft allerdings bei dem am meisten verwendeten 2D-API GDI geschlampt. Die 2D-Hardwarebeschleunigung wurde bei der Neuauflage des GDI nicht implementiert. Stattdessen rendert GDI unter Vista den Fensterinhalt mit der CPU in einen Hauptspeicherpuffer des DWM, der das fertige Fenster an die Grafikkarte weiterleitet. Ferner kann der DWM immer nur die GDI-Befehle eines Fensters bearbeiten. So entsteht unter Vista ein Bottleneck, da alle anderen Fenster warten müssen.
Das ist nicht nur langsam, sondern verbraucht auch jede Menge Speicher. Bei 10 bis 15 Fenstern auf dem Desktop benötigt der DWM bei aktivierter Aero-Oberfläche oft 100 MByte und mehr für sich.
Mit Windows 7 hatte Microsoft ein Einsehen. Das GDI ist nun wieder hardwarebeschleunigt. Der DWM leitet GDI-Befehle nun direkt an die Grafikhardware weiter ohne einen Bottleneck zu erzeugen. Das subjektive Performanceempfinden ist dadurch viel höher als bei Vista. Voraussetzungen dafür sind eine Grafikkarte und ein Treiber, die WDDM 1.1[24] unterstützen. Steven Sinofsky, der die Entwicklung von Windows 7 geleitet hat, muss man neidlos zugestehen, dass er in vielen Bereichen den Fokus auf die richtigen Dinge gelegt hat und umsetzen ließ. Steve Ballmer hat ihn für seine Leistung zu einem von fünf Präsidenten bei Microsoft befördert.
Sinofsky hatte außer Ballmer niemand zugetraut, ein verkorkstes Betriebssystem wieder flott zu machen. Vorher leitete er die Entwicklung von Office 2007, das sich von seinem Vorgänger Office 2003 hauptsächlich nur optisch durch das Ribbon-Interface unterschied. Er galt damals als Mann, der auf Effekthascherei aus ist.
Die Entwickler, die GDI+ zum größten Teil ignoriert haben, können sich damit trösten, dass sie auf das richtige Pferd gesetzt haben. Inzwischen hat Microsoft GDI+ faktisch für tot erklärt. Mit Windows 7 kommt zusätzlich zu GDI und GDI+ ein ganz neues API, dass sich Direct2D[25] nennt.
Es nutzt Hardwarebeschleunigung, bietet einen hohen Funktionsumfang und kann sogar in GDI-Displaykontexte zeichnen. Anders ausgedrückt: Direct2D bietet die Geschwindigkeit von GDI beim Funktionsumfang von GDI+. Selbst wenn mangels geeigneter Grafikkarte auf Softwarerendering zurückgegriffen werden muss, liegt die Geschwindigkeit oberhalb von GDI+. Sie kann sogar mit Quartz2D mithalten.
Direct2D ist inzwischen auf Vista rückportiert worden. Für Windows XP wird es aber keine Implementierung mehr geben. Bis zur Adaption durch Softwareentwickler wird also noch eine Zeit vergehen. Heute traut sich noch niemand, eine Software zu entwickeln, die mindestens Windows Vista voraussetzt.
Letztendlich ist GDI+ nunmehr ein weiteres API, dass auf absehbare Zeit in jeder neuen Windows-Version aus Gründen der Kompatibilität als Ballast mitgeschleppt werden muss. Das gehört zu den Dingen, die die Anwender für vermeidbare Fehlentwicklungen bei Microsoft hinzunehmen haben.
Mit Windows 7 kann Microsoft im Gegensatz zu Vista nicht nur 3D-Grafik, sondern auch die in der Praxis wesentlich häufig vorkommendere 2D-Grafik wieder mit Hardwarebeschleunigung darstellen. Zudem wurde der mit Vista eingeführte Display Window Manager um das Manko bereiningt, nur jeweils GDI-Befehle eines einzigen Fensters abarbeiten zu können.
Eine große Leistung ist das allerdings nicht, sondern die Beseitigung eines schweren Mangels in Vista. Im Endeffekt wurde nur der Zustand für das GDI wiederhergestellt, wie er von Windows NT 3.1 bis zu Windows XP bestand. Vista führte zwar 2,5D-Hardwarelayering für Fenster ein und brachte erstmals eine akzeptable Performance für GDI+, jedoch hat GDI+ kaum Praxisrelevanz.
Neu in Windows 7 ist das Direct2D-API. Es bietet die Performance von GDI, aber eine Funktionalität, die die von GDI+ noch übersteigt. Besonders stolz ist Microsoft dabei auf das schnelle Rendering von Fonts mit der Anti-Aliasing-Technologie ClearType. Dem Fontrendering unter Direct2D hat Microsoft daher den eigenen Namen DirectWrite spendiert.
Unter Windows 7 profitieren Nutzer vor allem von der wiederhergestellten Hardwarebeschleunigung im GDI. Dieses API nutzen über 95 Prozent aller Anwendungen, zum Teil über High-Level-APIs wie der Windows Presentation Foundation (WPF). Bis Softwarehersteller damit beginnen, Programme für Direct2D zu entwickeln, wird noch einige Zeit vergehen. Solche Anwendungen laufen nämlich nicht unter Windows XP.
URLs in diesem Artikel:
[1] = http:/
[2] = http:/
[3] = http:/
[4] = http:/
[5] = http:/
[6] = http:/
[7] = http:/
[8] = http:/
[9] = http:/
[10] = http:/
[11] = http:/
[12] = http:/
[13] = http:/
[14] = http:/
[15] = http:/
[16] = http:/
[17] = http:/
[18] = http:/
[19] = http:/
[20] = http:/
[21] = http:/
[22] = http:/
[23] = http:/
[24] = http:/
[25] = http:/