A GDI ( Graphics Device Interface , Graphical Device Interface ) a Microsoft Windows felhasználói felületét (GDI ablakkezelő) alkotó három fő összetevő vagy "alrendszer" egyike, a kernellel és a Windows API -val együtt .
A GDI egy Windows interfész grafikus objektumok megjelenítésére és megjelenítésére szolgáló eszközökhöz, például monitorokhoz és nyomtatókhoz.
A GDI felelős a vonalak és görbék rajzolásáért, a betűtípusok megjelenítéséért és a paletták kezeléséért. Nem felelős az ablakok, menük stb. rajzolásáért, ez a feladat a user32.dll -ben található és GDI-n alapuló felhasználói alrendszerhez van hozzárendelve. A GDI ugyanazokat a funkciókat hajtja végre, mint a QuickDraw Mac OS rendszeren .
A hardverhez való közvetlen hozzáférés helyett a GDI használatának egyik előnye a különböző eszközökkel végzett munka egyesítése. A GDI használatával ugyanazokat a funkciókat rajzolhatja meg különböző eszközökre, például képernyőre vagy nyomtatóra, szinte ugyanazokat a képeket kapva rajtuk. Ez a képesség sok WYSIWYG Windows-alkalmazás középpontjában áll .
Az egyszerű játékok, amelyek nem igényelnek gyors grafikát, használhatják a GDI-t. A GDI azonban nem biztosít jó minőségű animációt, mivel nem képes szinkronizálni a framebufferrel . A GDI-ben sincs raszterezés a 3D grafika megjelenítéséhez. A modern játékok DirectX -et vagy OpenGL -t használnak , amelyek több hardverfunkcióhoz biztosítanak hozzáférést a programozóknak.
A képernyőn vagy nyomtatón megjelenített szövegek és képek attribútumainak meghatározásához egy eszközkontextusnak nevezett szoftverobjektumot (Device Context, DC) használnak. A DC, mint a legtöbb GDI objektum, magában foglalja a megvalósítás részleteit és adatait, és nem érhető el közvetlenül.
Minden rajzhoz HDC (Handle DC) objektum szükséges. Nyomtatóra történő kiadáskor a HDC-t a CreateDC meghívásával kapjuk meg, és speciális funkciókat hívunk meg, hogy a nyomtatott dokumentum új oldalára ugorjanak. Képernyőn való megjelenítéskor használhatjuk a CreateDC-t is, de ez azt eredményezi, hogy az összes ablak tetejére rajzol a határain kívül, ezért általában a GetDC és a BeginPaint hívások segítségével rajzolnak a képernyőre, amelyek már nem tartoznak a GDI-hez, hanem a FELHASZNÁLÓ részre, és visszaadja az ablak vágási régiójára utaló kontextust.
Funkcionalitás:
A Windows 9x és korábbi verziókban 16 bites GDI.DLL-ben van megvalósítva, amely viszont betölti a DLL-ként implementált videokártya-illesztőprogramot. A videokártya illesztőprogramja eredetileg köteles volt végrehajtani az összes rajzolást általában, beleértve a bittérképeken keresztüli rajzolást a memóriában képernyő formátumban. Később megjelent a DIBENG.DLL, amelyben a tipikus formátumú bittérképekre való rajzolást valósították meg, a meghajtónak minden hívást át kellett adnia, kivéve azokat, amelyekhez a videokártya hardveres gyorsítóját használta.
A nyomtató-illesztőprogram ugyanilyen módon volt betöltve, és ugyanazzal a felülettel rendelkezett „felülről”, de „alulról”, ahelyett, hogy a memóriába / hardverre rajzolt volna, a nyomtatóparancsok sorozatát generálta és elküldte a Job objektumnak. Ezek a parancsok általában binárisak és nem ember által olvashatóak, vagy PostScript parancsok voltak.
Windows NT - ben teljesen átírták a GDI-t a semmiből, a C ++- ban pedig (a pletykák szerint a Microsoftnak akkor még nem volt fordítója erre a nyelvre és cfrontot használtak). Az alkalmazások API-ja nem változott (kivéve a Bezier-görbék hozzáadását), az illesztőprogramok esetében - a C nyelven a C ++-ban megvalósított belső elemek körüli burkolók (például BRUSHOBJ_pvGetRbrush).
Maga a GDI a WINSRV.DLL-ben az első helyre került a CSRSS.EXE folyamatban, kezdve a win32k.sys NT4-gyel. Ott rakták be a sofőröket. A DIBENG.DLL átírásra került, és ugyanoda került át, mint az EngXxx - EngTextOut és mások híváskészlete. A driver-GDI-DIBENG interakció logikája megközelítőleg változatlan maradt.
Felhasználói módban a GDI32.DLL speciális rendszerhívások halmazaként valósul meg, amelyek a win32k.sys fájlhoz vezetnek (az NT4 előtt a CsrClientCallServer hívás körül, amely üzenetet küldött a CSRSS.EXE-nek).
A Windows Vista bemutatta a WDDM illesztőprogram-modellt , amely megszüntette a 2D grafikus hardver használatának lehetőségét. WDDM használatakor minden GDI-alkalmazás (vagyis az összes szokásos Windows UI rendszerrész - ablakcímek és keretek, asztal, tálca stb.) a cdd.dll (Canonical Display Driver) [1] GDI-illesztőprogramot használja , amely a néhány bittérkép a memóriában, minden ablakhoz saját (az ablak tartalma elkezdett emlékezni a memóriában, előtte a Windows soha nem csinálta ezt, és mindig újrarajzolta az ablakokat, kivéve néhány speciális ablakot a CS_SAVEBITS jelzővel). A cdd.dll fájlból származó képeket a dwm.exe (Desktop Window Manager) folyamat kéri le, amely egy Direct3D alkalmazás, amely a Direct3D segítségével "ablakképeket" rajzol a fizikai képernyőre.
Maga a WDDM-illesztőprogram csak a DirectDraw-t és a Direct3D-t támogatja, és semmi köze sem a GDI-hez, sem a win32k.sys-hez, a kernel dxgkrnl.sys moduljához kapcsolódik.
A Windows nyomtatási alrendszert erősen kritizálják, különösen a CUPS -hez képest .
Okok: a nyomtatási feladatfolyam bináris formátuma (a CUPS-ben ez PostScript) és ennek a folyamnak a feldolgozása több DLL formájában ugyanazon a SPOOLSV.EXE folyamaton belül (a CUPS ehelyett egy szokásos többfolyamatos folyamatot használ, mint a pstoraster | rastertoepson | párhuzamos, amelyet ha akar, normál UNIX shellből is futtathat). Így a CUPS támogatja a nyomtatási feladatszűrők fejlesztését (például díjköteles szállodai nyomtatókhoz) még olyan szkriptnyelveken is, mint a Perl .
Itt azonban inkább a GDI alatti komponensekről beszélünk.
A CUPS-nek azonban komoly problémái vannak a WinPrinterek támogatásával, mint az összes olcsó Hewlett-Packard lézernyomtatóval. Mivel nem támogatják az elterjedt PCL formátumot, hatalmas, bonyolult konfigurálást és csomagokat igényelnek, mint például a HP OfficeJet (a FreeBSD "hpoj" portja). Ugyanakkor a CUPS tökéletesen támogatja a tintasugaras nyomtatókat, a drága Hewlett-Packard lézernyomtatókat és a PostScript nyomtatókat.
A UNIX-szerű operációs rendszerekben, például a Linuxban használt X11 technológia alacsonyabb szintjei .
Ugyanakkor az X11 szolgáltatásaiban gyengébb, mint a GDI (például problémák vannak az eszközfüggetlen színek megvalósításával), és a GDI teljes analógjának eléréséhez számos könyvtárat kell hozzáadni, például SDL -t. .
| Windows komponens | |
| Microsoft Windows GDI+ | |
|---|---|
| Alkatrész típusa | Microsoft Windows szoftver és összetevő [d] |
| Tartalmazza |
Windows XP Windows Server 2003 Windows Vista Starter |
| Lecserélve | Microsoft Windows GDI |
| Ki lett cserélve | Asztali ablakkezelő |
A Windows XP megjelenésével megjelent az alrendszer leszármazottja, a C++ [2] alapú GDI+ . A GDI+ alrendszer 600 függvényből álló "lapos" halmazként érhető el a gdiplus.dll fájlban . Ezek a függvények 40 C++ osztályba vannak "csomagolva". A Microsoft nem tervezi olyan kódok támogatását, amelyek közvetlenül érik el a lapos készletet, nem pedig C++ osztályokon és metódusokon keresztül. A .NET-keretrendszer alternatív C++ burkolóosztályokat kínál a System.Drawing..
A GDI+ egy továbbfejlesztett 2D grafikus környezet, amely olyan funkciókat ad hozzá, mint az élsimítás , lebegőpontos koordináták , színátmenetek kitöltése , belső munkaképesség olyan grafikus formátumokkal, mint a JPEG és PNG , a vágási régiók sokkal jobb megvalósítása a lebegőpontos koordináták használatának lehetőségével bennük (a 16 bites egész számok helyett), és alkalmazza rájuk a World Transform-ot, átalakítsa kétdimenziós mátrixokat stb. A GDI + ARGB színeket használ. Ezeket a szolgáltatásokat a Windows XP felhasználói felülete használja, és az alapul szolgáló grafikus rétegben való jelenlétük megkönnyíti a vektorgrafikus rendszerek, például a Flash vagy az SVG használatát .
A GDI+ dinamikus könyvtárak a Windows korábbi verzióiban használható alkalmazásokkal terjeszthetők.
A GDI+ hasonló az Apple Quartz 2D alrendszeréhez és a nyílt forráskódú libart és Cairo könyvtárhoz .
A GDI+ nem más, mint a hagyományos GDI feletti burkolókészlet. A Windows 7 rendelkezik egy új Direct2D API -val , amely nagyjából ugyanaz, de „felülről lefelé” egészen a videokártya illesztőprogramjáig implementálva (pontosabban, ebben az illesztőprogramban használ néhány Direct3D képességet), és hardveres gyorsítást is tud használni. egy 3D-s videoprocesszor néhány 2D-s objektum rajzolásához (élsimítás stb.)
2004. szeptember 14- én a GDI+ és más grafikus API-k biztonsági rését fedezték fel a JPEG könyvtárkód hibája miatt. Ez a hiba tetszőleges kódfuttatást tett lehetővé bármely Windows rendszeren. 2004. október 12-én megjelent egy javítás a sérülékenység javítására [3] .