Dela via

Jämföra Direct2D- och GDI-maskinvaruacceleration

  • Artikel

Direct2D och GDI är både API:er för omedelbar läges-2D-återgivning och båda erbjuder en viss grad av maskinvaruacceleration. Det här avsnittet utforskar skillnaderna mellan Direct2D och GDI, inklusive tidigare och nuvarande skillnader i maskinvaruaccelerationsfunktionerna i båda API:erna.

Det här avsnittet innehåller följande delar:

Skillnader mellan Direct2D och GDI

GDI- återger ogenomskinliga, aliasgeometrier som polygoner, ellipser och linjer. Den renderar alias och ClearType-text, och den kan stödja genomskinlighetsblandning via AlphaBlend-API:et. Dess hantering av transparens är dock inkonsekvent och de flesta GDI-API:er ignorerar helt enkelt alfakanalen. Få GDI-API:er garanterar vad alfakanalen kommer att innehålla efter en åtgärd. Ännu viktigare är att GDI:s återgivning inte enkelt mappas till 3D-åtgärder, och en modern GPU återger mest effektivt med 3D-delen av sin renderingsmotor. Till exempel är Direct2D-aliaslinjer utformade för att implementeras helt enkelt som två trianglar som återges på GPU:n, medan GDI använder Bresenhams linjeritningsalgoritm.

Direct2D- återger opaka, transparenta, aliasade och anti-aliasade primitiver. Moderna UIs använder ofta transparens och animering. Direct2D gör det enklare att skapa ett modernt användargränssnitt eftersom det har strikta garantier för hur det accepterar och renderar transparent innehåll, och alla dess primitiver återges med maskinvaruacceleration. Direct2D är inte en ren supermängd av GDI: primitiver som skulle ha varit orimligt långsamma när de implementerades på en GPU finns inte i Direct2D. Eftersom Direct2D skapas med den här betoningen på 3D-acceleration är det också enkelt att använda med Direct3D.

Sedan Windows NT 4 har GDI- körts i kernelläge. Programmet anropar GDI som sedan anropar dess motsvarighet i kernelläge som skickar primitiverna till sin egen drivrutinsmodell. Den här drivrutinen skickar sedan resultatet till visningsdrivrutinen för globalt kernelläge.

Från och med Windows 2000 har GDI- och GDI-drivrutinerna körts i ett oberoende utrymme i kerneln som kallas "sessionsutrymme". Ett sessionsadressutrymme skapas för varje inloggningssession och varje instans av GDI körs separat i det här distinkta kernellägets adressutrymme. Direct2D körs dock i användarläge och skickar ritkommandon via direct3D-drivrutinen i användarläge till drivrutinen för kernelläge.

bild 1 – direct2d jämfört med gdi

GDI- och Direct2D-maskinvaruacceleration

Den viktigaste skillnaden mellan Direct2D och GDI maskinvaruacceleration är den underliggande tekniken som driver dem. Direct2D ligger ovanpå Direct3D och GDI har en egen drivrutinsmodell, GDI Device Driver Interface (DDI), som motsvarar GDI-primitiverna. Direct3D-drivrutinsmodellen motsvarar vad 3D-renderingsmaskinvaran i en GPU återger. När GDI DDI först definierades var de flesta maskinvaruenheter för visningsacceleration inriktade på GDI-primitiverna. Med tiden lades allt större vikt vid 3D-spelacceleration och mindre på programacceleration. Som en följd av detta var BitBlt-API:et maskinvaruaccelererat och de flesta andra GDI-åtgärder var inte maskinvaruaccelererade.

Detta lade grunden för en sekvens med ändringar i hur GDI återges på skärmen. Följande bild visar hur GDI-visningsåtergivningen har ändrats från Windows XP till Windows 7.

bild 2 – utvecklingen av gdi-visningsrendering

Det fanns också ett antal ytterligare faktorer som orsakade ändringar i GDI- drivrutinsmodell, enligt beskrivningen nedan.

Öka komplexiteten och storleken på visningsdrivrutiner

3D-drivrutiner har blivit mer komplexa med tiden. Mer komplex kod tenderar att ha fler defekter, vilket gör det fördelaktigt för drivrutinen att finnas i användarläge där ett drivrutinsfel inte kan orsaka en systemomstart. Som du ser i bilden ovan är visningsdrivrutinen uppdelad i en komplex komponent i användarläge och en enklare komponent i kernelläget.

Problem med att synkronisera sessions- och globala kerneladressutrymmen

I Windows XP finns en visningsdrivrutin i två olika adressutrymmen: sessionsutrymme och kernelutrymme. Delar av drivrutinen måste svara på händelser som till exempel strömhanteringshändelser. Detta måste synkroniseras med drivrutinstillståndet i sessionsadressutrymmet. Det här är en svår uppgift och kan leda till defekter när visningsdrivrutiner försöker hantera dessa distinkta adressutrymmen.

Hantering av sammansatta fönster

Desktop Window Manager (DWM), den sammansättningsfönsterhanterare som introducerades i Windows 7, renderar alla fönster till off-screen-ytor och komponerar dem sedan tillsammans för att visas på skärmen. Detta kräver GDI- för att kunna rendera till en yta som sedan återges av Direct3D för visning. Detta innebar ett problem i XP-drivrutinsmodellen, eftersom GDI och Direct3D var parallella drivrutinsstackar.

I Windows Vista implementerades därför den GDI- DDI-visningsdrivrutinen eftersom Microsoft levererade Canonical Display Driver (CDD) som renderade GDI-innehåll till en systemminnesbitmapp som skulle skrivas till skärmen.

GDI-rendering i Windows 7

Drivrutinsmodellen som används i Windows Vista kräver att varje GDI- fönster backas upp av både en videominnesyta och en systemminnesyta. Detta resulterade i att systemminnet användes för varje GDI-fönster.

Därför ändrades GDI- igen i Windows 7. I stället för att återge till en systemminnesyta ändrades GDI för att rendera till ett aperturminnessegment. Bländarminnet kan uppdateras från videominnesytan som innehåller fönsterinnehållet. GDI kan renderas tillbaka till aperturminnet och resultatet kan sedan skickas tillbaka till fönsterytan. Eftersom bländarminnessegmentet kan adresseras av GPU:n kan GPU:n påskynda uppdateringarna av videominnesytan. Till exempel accelereras textrendering, BitBlts, AlphaBlend, TransparentBlt och StretchBlt i dessa fall.

Kontrasterande Direct2D- och GDI-acceleration i Windows 7

Direct2D- och GDI- är båda 2D-API:er för återgivning i omedelbart läge och maskinvaruaccelererade. Det finns dock ett antal skillnader som finns kvar i båda API:erna.

Plats för resurser

GDI- underhåller sina resurser, särskilt bitmappar, i systemminnet som standard. Direct2D- behåller sina resurser i videominnet på bildskärmskortet. När GDI behöver uppdatera videominnet måste detta göras via bussen, såvida inte resursen redan finns i minnessegmentet för bländare eller om åtgärden kan uttryckas direkt. Direct2D kan däremot helt enkelt översätta sina primitiver till Direct3D-primitiver eftersom resurserna redan finns i videominnet.

Återgivningsmetod

För att upprätthålla kompatibiliteten utför GDI en stor del av sin återgivning till bländarminnet med hjälp av processorn. Däremot översätter Direct2D sina API-anrop till Direct3D-primitiver och ritoperationer. Resultatet återges sedan på GPU:n. En del GDI-återgivning utförs på GPU:n när bländarminnet kopieras till videominnesytan som representerar GDI-fönstret.

Skalbarhet

Direct2D-:s renderingsanrop är alla oberoende kommandoströmmar till GPU:n. Varje Direct2D-fabrik representerar en annan Direct3D-enhet. GDI- använder en kommandoström för alla program i systemet. GDI:s metod kan leda till en ökning av kostnaderna för GPU- och CPU-renderingskontexter.

Plats

Direct2D- fungerar helt i användarläge, inklusive Direct3D-körningstid och Direct3D-drivrutinen för användarläget. Detta hjälper till att förhindra systemkrascher som orsakas av kodfel i kerneln. GDI-har dock de flesta av sina funktioner i sessionsutrymme i kernelläge, med dess API-yta i användarläge.

Tillgänglighet för maskinvaruacceleration

GDI- är maskinvaruaccelererad i Windows XP och accelereras i Windows 7 när Skrivbordsfönsterhanteraren körs och en WDDM 1.1-drivrutin används. Direct2D- är maskinvaruaccelererad på nästan alla WDDM-drivrutiner och om DWM används eller inte. På Vista renderas GDI alltid på processorn.

Presentationsmodell

När Windows först utformades fanns det inte tillräckligt med minne för att tillåta att varje fönster lagras i sin egen bitmapp. Som ett resultat renderade GDI- alltid logiskt direkt till skärmen, med olika klippningsområden tillämpade för att säkerställa att ett program inte renderade utanför sitt fönster. I Direct2D--modellen renderas ett program till en serverbuffert och resultatet visas när programmet är klart. Detta gör att Direct2D kan hantera animeringsscenarier mycket mer smidigt än vad GDI kan.

Slutsats

Befintlig GDI- kod fortsätter att fungera bra under Windows 7. Men när du skriver ny grafikrenderingskod bör Direct2D- beaktas, eftersom den drar bättre nytta av moderna GPU:er.