GDI ( Graphics Device Interface , Graphical Device Interface ) är en av de tre huvudkomponenterna eller "undersystemen", tillsammans med kärnan och Windows API , som utgör användargränssnittet (GDI-fönsterhanteraren) i Microsoft Windows .
GDI är ett Windows-gränssnitt för att representera grafiska objekt och skicka dem till visningsenheter som bildskärmar och skrivare.
GDI ansvarar för att rita linjer och kurvor, visa teckensnitt och hantera paletter. Det är inte ansvarigt för att rita fönster, menyer, etc., denna uppgift är tilldelad användarens delsystem, som finns i user32.dll och baserat på GDI. GDI utför samma funktionalitet som QuickDraw på Mac OS .
En av fördelarna med att använda GDI istället för direkt åtkomst till hårdvara är att arbeta med olika enheter. Med GDI kan du rita samma funktioner på olika enheter, till exempel en skärm eller en skrivare, och få nästan samma bilder på dem. Denna förmåga ligger i hjärtat av många WYSIWYG- applikationer för Windows.
Enkla spel som inte kräver snabb grafik kan använda GDI. GDI tillhandahåller dock inte högkvalitativ animering, eftersom den inte har möjlighet att synkronisera med framebuffer . Även i GDI finns det ingen rastrering för att rendera 3D-grafik. Moderna spel använder DirectX eller OpenGL , vilket ger programmerare tillgång till fler hårdvarufunktioner.
För att definiera attributen för text och bilder som visas på en skärm eller skrivare, används ett programvaruobjekt som kallas enhetskontext (Device Context, DC). En DC, som de flesta GDI-objekt, kapslar in implementeringsdetaljer och data i sig och kan inte nås direkt.
Varje ritning kräver ett HDC-objekt (Handle DC). Vid utskrift till en skrivare erhålls HDC genom att anropa CreateDC, och specialfunktioner anropas på den för att hoppa till en ny sida i det utskrivna dokumentet. När du visar på skärmen kan du också använda CreateDC, men detta kommer att leda till att man ritar ovanpå alla fönster utanför deras gränser, därför används vanligtvis GetDC och BeginPaint-anrop för att rita på skärmen, som inte längre tillhör GDI, men till ANVÄNDARE och returnera ett sammanhang som hänvisar till fönstrets klippområde .
Funktionalitet:
I Windows 9x och tidigare är det implementerat i en 16-bitars GDI.DLL, som i sin tur laddar grafikkortsdrivrutinen implementerad som en DLL. Grafikkortets drivrutin var ursprungligen skyldig att implementera all ritning i allmänhet, inklusive ritning genom bitmappar i minnet i skärmformat. Senare dök DIBENG.DLL upp, där ritning på bitmappar av typiska format implementerades, föraren var skyldig att skicka alla anrop till den, förutom de för vilka han använde grafikkortets hårdvaruaccelerator.
Skrivardrivrutinen laddades på samma sätt och hade samma gränssnitt "uppifrån", men "underifrån", istället för att rita in minnet / på hårdvaran, genererade den sekvenser av skrivarkommandon och skickade dem till Job-objektet. Dessa kommandon var vanligtvis antingen binära och icke-mänskliga läsbara eller PostScript.
I Windows NT skrevs GDI om helt från början, och i C++ (enligt rykten hade Microsoft inte en kompilator för detta språk vid den tiden och de använde cfront). API:et för applikationer har inte ändrats (förutom att lägga till Bezier-kurvor), för drivrutiner - omslag i C-språket runt internerna implementerade i C ++ (som BRUSHOBJ_pvGetRbrush).
GDI själv placerades först i WINSRV.DLL i CSRSS.EXE-processen, med början med NT4 i win32k.sys. Förarna lastades där. DIBENG.DLL har skrivits om och flyttats till samma plats som uppsättningen samtal EngXxx - EngTextOut och andra. Logiken för interaktion mellan drivrutinen och GDI-DIBENG har förblivit ungefär densamma.
GDI32.DLL i användarläge implementeras som en uppsättning speciella systemanrop som leder till win32k.sys (före NT4, som omslag runt CsrClientCallServer-anropet som skickade ett meddelande till CSRSS.EXE).
Windows Vista introducerade WDDM- drivrutinsmodellen , som tog bort möjligheten att använda 2D-grafikhårdvara. När du använder WDDM använder alla GDI-applikationer (det vill säga alla vanliga Windows UI-systemdelar - fönstertitlar och ramar, skrivbord, aktivitetsfält, etc.) cdd.dll (Canonical Display Driver) [1] GDI-drivrutinen , som bygger på några bitmappar i minnet, sina egna för varje fönster (innehållet i fönstret började komma ihåg i minnet, innan dess gjorde Windows aldrig detta och ritade alltid om fönster, förutom några speciella fönster med flaggan CS_SAVEBITS). Bilder från cdd.dll hämtas av processen dwm.exe (Desktop Window Manager), som är en Direct3D-applikation som ritar "fönsterbilder" på den fysiska skärmen via Direct3D.
Själva WDDM-drivrutinen stöder bara DirectDraw och Direct3D och har inget att göra med varken GDI eller win32k.sys, den gränssnitt mot dxgkrnl.sys-modulen i kärnan.
Windows-utskriftsundersystemet är mycket kritiserat, särskilt jämfört med CUPS .
Orsaker: det binära formatet för utskriftsjobbströmmen (i CUPS är detta PostScript) och implementeringen av att bearbeta denna ström i form av flera DLL:er i samma SPOOLSV.EXE-process (CUPS använder istället en vanlig flerprocesspipeline som pstoraster | rastertoepson | parallell, som du kan köra om du vill från ett vanligt UNIX-skal). Således stöder CUPS utvecklingen av utskriftsjobbfilter (till exempel för avgiftsbelagda hotellskrivare) även i skriptspråk som Perl .
Men här talar vi mer om komponenterna som ligger under GDI.
CUPS har dock allvarliga problem med att stödja WinPrinters som alla billiga Hewlett-Packard laserskrivare. Eftersom de inte stöder det vanliga PCL-formatet kräver de enorma, komplexa att konfigurera och bygga paket, som HP OfficeJet (FreeBSDs "hpoj"-port). Samtidigt har CUPS perfekt stöd för bläckstråleskrivare, dyra Hewlett-Packard-laserskrivare och PostScript-skrivare.
De lägre nivåerna av X11 -tekniken som används i UNIX-liknande operativsystem som Linux .
Samtidigt är X11 sämre på funktioner än GDI (det finns till exempel problem med implementering av enhetsoberoende färger), och för att få en komplett analog av GDI måste du lägga till ett antal bibliotek, som SDL .
| Windows -komponent | |
| Microsoft Windows GDI+ | |
|---|---|
| Komponenttyp | Microsoft Windows -programvara och komponent [d] |
| Ingår i |
Windows XP Windows Server 2003 Windows Vista Starter |
| Ersatt | Microsoft Windows GDI |
| Har bytts ut | Desktop Window Manager |
Med lanseringen av Windows XP dök en ättling till delsystemet, GDI+, baserat på C++ [2] . GDI+-undersystemet är tillgängligt som en "platt" uppsättning av 600 funktioner implementerade i gdiplus.dll . Dessa funktioner är "inpackade" i 40 C++-klasser. Microsoft planerar inte att tillhandahålla stöd för kod som kommer åt den platta uppsättningen direkt, snarare än genom C++-klasser och -metoder. .NET Framework tillhandahåller en uppsättning alternativa C++-omslagsklasser i System.Drawing..
GDI+ är en förbättrad 2D-grafikmiljö som lägger till funktioner som kantutjämning , flyttalskoordinater , gradientfyllningar , möjligheten att arbeta internt med grafiska format som JPEG och PNG , en mycket bättre implementering av urklippsregioner med möjlighet att använda flyttalskoordinater i dem (snarare än 16-bitars heltal) och tillämpa World Transform på dem, transformera tvådimensionella matriser, etc. GDI + använder ARGB- färger. Dessa funktioner används i Windows XP-användargränssnittet, och deras närvaro i det underliggande grafiklagret gör det lättare att använda vektorgrafiksystem som Flash eller SVG .
GDI+ dynamiska bibliotek kan distribueras med applikationer för användning på tidigare versioner av Windows.
GDI+ liknar Apples Quartz 2D -delsystem och biblioteken med öppen källkod libart och Cairo .
GDI+ är inget annat än en uppsättning omslag över vanliga GDI. Windows 7 har en ny Direct2D API , som är ungefär densamma, men implementerad "från topp till botten" ända upp till grafikkortsdrivrutinen (mer exakt, den använder vissa Direct3D-funktioner i den här drivrutinen), och kan använda hårdvaruacceleration - det är en 3D-videoprocessor för att rita vissa 2D-objekt (kantutjämning, etc.)
Den 14 september 2004 upptäcktes en sårbarhet i GDI+ och andra grafik-API:er på grund av en bugg i JPEG-bibliotekskoden. Denna bugg möjliggjorde exekvering av godtycklig kod på alla Windows-system. En patch för att åtgärda sårbarheten släpptes den 12 oktober 2004 [3] .