Direct2D- en GDI-hardwareversnelling vergelijken
Direct2D- en GDI- zijn beide directe 2D-rendering-API's en beide bieden enige mate van hardwareversnelling. In dit onderwerp worden de verschillen tussen Direct2D en GDI besproken, inclusief eerdere en huidige verschillen in de hardwareversnellingsfuncties van beide API's.
Dit onderwerp bevat de volgende onderdelen:
- verschillen tussen Direct2D en GDI-
- GDI- en Direct2D-hardwareversnelling
- GDI-rendering op Windows 7
- Contrasterende Direct2D- en GDI-versnelling in Windows 7
- Conclusie
Verschillen tussen Direct2D en GDI
GDI rendert ondoorzichtige, alias-geometrieën zoals veelhoeken, ellipsen en lijnen. Het rendert alias- en ClearType-tekst en biedt ondersteuning voor transparantiemixing via de AlphaBlend-API. De verwerking van transparantie is echter inconsistent en de meeste GDI-API's negeren het alfakanaal. Enkele GDI-API's garanderen wat het alfakanaal zal bevatten na een bewerking. Belangrijker is dat de rendering van GDI niet eenvoudig compatibel is met 3D-bewerkingen, en dat een moderne GPU het efficiëntst rendert op het 3D-gedeelte van de rendering-engine. Direct2D's aliaslijnen zijn bijvoorbeeld ontworpen om eenvoudig te worden geïmplementeerd als twee driehoeken die worden weergegeven op de GPU, terwijl GDI gebruikmaakt van het tekenalgoritmen voor lijnen van Bresenham.
Direct2D- geeft ondoorzichtige, transparante, gealiasde en anti-gealiasde primitieve vormen weer. Moderne UIS's maken vaak gebruik van transparantie en animatie. Direct2D maakt het eenvoudiger om een moderne gebruikersinterface te maken, omdat het strikte garanties biedt voor hoe het transparante elementen verwerkt en weergeeft, en alle primitieven worden weergegeven met hardwareversnelling. Direct2D is geen pure superset van GDI-: primitieven die onredelijk traag zouden zijn geweest bij implementatie op een GPU zijn niet aanwezig in Direct2D. Omdat Direct2D is gebouwd met deze nadruk op 3D-versnelling, is het ook eenvoudig te gebruiken met Direct3D.
Sinds Windows NT 4 is GDI- uitgevoerd in de kernelmodus. De toepassing roept GDI aan die vervolgens de tegenhanger van de kernelmodus aanroept die de primitieven doorgeeft aan een eigen stuurprogrammamodel. Dit stuurprogramma verzendt vervolgens de resultaten naar het weergavestuurprogramma voor de globale kernelmodus.
Vanaf Windows 2000 worden GDI- en de GDI-stuurprogramma's uitgevoerd in een onafhankelijke ruimte in de kernel met de naam 'sessieruimte'. Er wordt een sessieadresruimte gemaakt voor elke aanmeldingssessie en elk exemplaar van GDI wordt onafhankelijk uitgevoerd in deze afzonderlijke adresruimte in de kernelmodus. Direct2D wordt echter uitgevoerd in de gebruikersmodus en geeft tekenopdrachten door via het Direct3D-stuurprogramma van de gebruikersmodus naar het kernelmodusstuurprogramma.
GDI- en Direct2D-hardwareversnelling
Het belangrijkste verschil tussen Direct2D en GDI hardwareversnelling is de onderliggende technologie die deze aanstuurt. Direct2D is gelaagd boven Direct3D en GDI heeft een eigen stuurprogrammamodel, de GDI Device Driver Interface (DDI), die overeenkomt met de GDI-primitieven. Het Direct3D-stuurprogrammamodel komt overeen met wat de 3D-renderinghardware in een GPU weergeeft. Toen de GDI DDI voor het eerst werd gedefinieerd, richt de meeste hardware voor weergaveversnelling zich op de GDI-primitieven. Na verloop van tijd werd steeds meer nadruk gelegd op 3D gameversnelling en minder op toepassingsversnelling. Als gevolg hiervan werd de BitBlt-API hardwareversneld en de meeste andere GDI-bewerkingen niet.
Dit maakt de weg vrij voor een reeks wijzigingen in hoe GDI- wordt weergegeven op het scherm. In de volgende afbeelding ziet u hoe de weergave van GDI is gewijzigd van Windows XP in Windows 7.
Er waren ook een aantal aanvullende factoren die wijzigingen in het GDI--stuurprogrammamodel veroorzaakten, zoals hieronder wordt uitgelegd.
Toenemende complexiteit en grootte van weergavestuurprogramma's
3D-stuurprogramma's zijn na verloop van tijd complexer geworden. Complexere code heeft meestal meer defecten, waardoor het voor het stuurprogramma nuttig is om te bestaan in de gebruikersmodus waarbij een stuurprogrammafout geen systeem opnieuw kan opstarten. Zoals u kunt zien in de bovenstaande afbeelding, is het weergavestuurprogramma onderverdeeld in een complex onderdeel van de gebruikersmodus en een eenvoudiger kernelmodusonderdeel.
Problemen met het synchroniseren van sessie- en algemene kerneladresruimten
In Windows XP bestaat er een weergavestuurprogramma in twee verschillende adresruimten: sessieruimte en kernelruimte. Onderdelen van het stuurprogramma moeten reageren op gebeurtenissen zoals energiebeheer-gebeurtenissen. Dit moet worden gesynchroniseerd met de status van de driver in de sessie-adresruimte. Dit is een moeilijke taak en kan leiden tot defecten wanneer weergavestuurprogramma's proberen om te gaan met deze afzonderlijke adresruimten.
Samengesteld vensterbeheer
De Desktop Window Manager (DWM), de compositorvensterbeheerder die is geïntroduceerd in Windows 7, rendert alle vensters naar off-screen oppervlakken en stelt deze vervolgens samen om op het scherm te worden weergegeven. Hiervoor moet GDI- kunnen renderen naar een oppervlak dat vervolgens door Direct3D wordt weergegeven. Dit was een probleem in het XP-stuurprogrammamodel, omdat GDI en Direct3D parallelle stuurprogrammastacks waren.
Als gevolg hiervan is in Windows Vista het GDI- DDI-beeldschermstuurprogramma geïmplementeerd als het door Microsoft geleverde Canonical Display Driver (CDD) dat GDI-inhoud weergeeft in een systeemgeheugenbitmap om op het scherm samengesteld te worden.
GDI-rendering in Windows 7
Het stuurprogrammamodel dat in Windows Vista wordt gebruikt, vereist dat elk GDI- venster wordt ondersteund door zowel een videogeheugenoppervlak als een systeemgeheugenoppervlak. Dit heeft geresulteerd in systeemgeheugen dat voor elk GDI-venster wordt gebruikt.
Daarom is GDI- opnieuw gewijzigd in Windows 7. In plaats van te renderen naar een systeemgeheugenoppervlak, is GDI gewijzigd voor het weergeven in een aperture-geheugensegment. De apertuurgeheugen kan worden bijgewerkt vanaf het video-geheugenoppervlak met de inhoud van het venster. GDI kan terug naar het apertuurgeheugen weergeven en het resultaat kan vervolgens naar het vensteroppervlak worden gestuurd. Omdat het geheugensegment van de aperture door de GPU kan worden aangesproken, kan de GPU deze updates naar het video-geheugenoppervlak versnellen. Tekstweergave, BitBlts, AlphaBlend, TransparentBlt en StretchBlt worden in deze gevallen bijvoorbeeld allemaal versneld.
Het vergelijken van Direct2D- en GDI-versnelling in Windows 7
Direct2D en GDI zijn beide 2D directe-modus rendering API's en zijn hardwareversneld. Er zijn echter een aantal verschillen die in beide API's blijven staan.
Locatie van bronnen
GDI- beheert standaard zijn resources, met name bitmaps, in het systeemgeheugen. Direct2D- beheert de resources in het videogeheugen op de beeldschermadapter. Wanneer GDI videogeheugen moet bijwerken, moet dit via de bus worden uitgevoerd, tenzij de resource zich al in het geheugensegment van het aperture bevindt of als de bewerking rechtstreeks kan worden uitgedrukt. Direct2D kan daarentegen eenvoudig de primitieven vertalen naar Direct3D-primitieven omdat de resources al in het videogeheugen staan.
Renderingmethode
Om compatibiliteit te behouden, voert GDI- een groot deel van de rendering uit naar het aperturegeheugen met behulp van de CPU. In Direct2D- worden de API-aanroepen daarentegen omgezet in Direct3D-primitieven en tekenbewerkingen. Het resultaat wordt vervolgens weergegeven op de GPU. Sommige GDI-rendering wordt uitgevoerd op de GPU wanneer het aperture-geheugen wordt gekopieerd naar het videogeheugenoppervlak dat het GDI-venster vertegenwoordigt.
Schaalbaarheid
Direct2D's renderingaanroepen zijn allemaal onafhankelijke opdrachtstromen naar de GPU. Elke Direct2D-fabriek vertegenwoordigt een ander Direct3D-apparaat. GDI- één opdrachtstroom gebruikt voor alle toepassingen op het systeem. De methode van GDI kan leiden tot een ophoping van GPU- en CPU-renderingcontextoverhead.
Locatie
Direct2D- werkt volledig in de gebruikersmodus, inclusief de Direct3D-runtime en het Direct3D-stuurprogramma van de gebruikersmodus. Dit helpt systeemcrashes te voorkomen die worden veroorzaakt door codefouten in de kernel. GDI-heeft echter de meeste functionaliteit in sessieruimte in kernelmodus, met het API-oppervlak in de gebruikersmodus.
Beschikbaarheid van hardwareversnelling
GDI- wordt hardwarematig versneld op Windows XP en wordt versneld op Windows 7 wanneer de Desktop Vensterbeheerder actief is en een WDDM 1.1-stuurprogramma wordt gebruikt. Direct2D- is hardware versneld op vrijwel elk WDDM-stuurprogramma, ongeacht of DWM wordt gebruikt. Op Vista wordt GDI altijd weergegeven op de CPU.
Presentatiemodel
Toen Windows voor het eerst werd ontworpen, was er onvoldoende geheugen om toe te staan dat elk venster in een eigen bitmap kan worden opgeslagen. Als gevolg hiervan werd GDI- altijd logisch op het scherm gerenderd, waarbij verschillende knipregio's zijn toegepast om ervoor te zorgen dat een toepassing niet buiten het venster wordt gerenderd. In het model Direct2D wordt een toepassing weergegeven in een backbuffer en wordt het resultaat weergegeven wanneer de toepassing klaar is met tekenen. Hierdoor kan Direct2D animatiescenario's veel vloeiender verwerken dan GDI kan.
Conclusie
Bestaande GDI--code blijft goed werken onder Windows 7. Bij het schrijven van nieuwe grafische renderingcode moet Direct2D- echter worden overwogen, omdat het beter gebruikmaakt van moderne GPU's.