Graphics Device Interface är ett API i Microsoft Windows som används för att representera grafiska objekt och överföra dem till utdataenheter, t.ex. skrivare och bildskärmar.

GDI ansvarar för uppgifter som att rita linjer och kurvor, återge teckensnitt och hantera paletter. Det är inte direkt ansvarigt för att rita fönster, menyer etc. Den uppgiften är reserverad för ett annat delsystem som byggs ovanpå GDI. Andra system har komponenter som liknar GDI, till exempel Macintosh QuickDraw och GNOME/GTK GDK/Xlib.

Den kanske viktigaste egenskapen hos GDI jämfört med mer direkta metoder för att komma åt maskinvaran är dess skalningsmöjligheter och abstraktion av målenheter. Med hjälp av GDI är det mycket enkelt att rita på flera enheter, t.ex. en skärm och en skrivare, och förvänta sig korrekt återgivning i varje fall. Denna möjlighet är central för alla What You See Is What You Get-applikationer för Microsoft Windows.

Enkla spel som inte kräver snabb grafikrendering använder GDI. GDI kan dock inte animera ordentligt eftersom det inte har någon synkronisering med rambufferten och saknar rasterisering för 3D. Moderna spel använder vanligen DirectX eller OpenGL i stället, som ger programmerarna möjlighet att använda funktioner i modern maskinvara.

Översikt och grundläggande begrepp

GDI är en högnivå‑grafikmotor som erbjuder en uppsättning objekt och funktioner för 2D‑grafik och utskrift. Några centrala begrepp är:

  • Device Context (HDC) – ett handtag som beskriver mål för ritoperationer (skärm, skrivare, minnesbitmap m.m.).
  • Penslar och penslar (brushes) – används för att fylla områden (färg, mönster, gradienter i GDI+).
  • Pen (penna) – används för att rita linjer och konturer med viss tjocklek och stil.
  • Font/teckensnitt – GDI hanterar typsnittsrendering via teckensnittsobjekt.
  • Bitmaps – både device‑dependent (DDB) och device‑independent (DIB) bitmaps för rasterdata.
  • Metafiler – vektorbaserade inspelningar av GDI‑anrop (WMF/EMF) som kan upprepas på olika enheter.

Tekniska egenskaper

GDI utför operationer som linjer, rektanglar, ellipser, banor, polylinjer, bitblt (block transfer) och rasteroperationer (ROP). Det stödjer också:

  • Palett‑hantering och färgmatchning mellan enheter.
  • Utskriftsstöd där samma GDI‑anrop kan riktas mot en skrivardrivrutin för högupplösta utskrifter.
  • Metafiler (WMF/EMF) som kan användas för att spara ritsekvenser och återuppspela dem mot olika enheter.
  • GDI32.dll som huvudbibliotek och ett antal kärnfunktioner i Win32 API.

Historia och varianter

GDI är en gammal och grundläggande del av Windows grafikstapel. För att möta moderna krav har Microsoft introducerat förbättringar och alternativa tekniker:

  • GDI+ – ett förbättrat API som ger bland annat antialiasing, alpha‑kanaler, avancerad bildhantering och gradienter. GDI+ används ofta i .NET:s System.Drawing-namespace.
  • Nyare grafikkit som Direct2D, DirectWrite och WPF erbjuder hårdvaruaccelererad rendering och bättre stöd för moderna skärmformat och textrendering.

Begränsningar och prestanda

GDI är inte designat för högpresterande, hårdvaruaccelererad grafik som moderna spel eller 3D‑applikationer. Vanliga begränsningar är:

  • Ingen direkt synkronisering mot videoram (inga vsync‑garantier), vilket försvårar jämn animation.
  • Begränsat stöd för hårdvaruacceleration; mycket av renderingen sker i CPU och i drivrutinernas mjukvarukod.
  • System och sessioner har kvoter för GDI‑objekt (penslar, pennor, bitmap‑handtag med mera); läckage av dessa objekt kan leda till att applikationen eller systemet får problem.
  • Inte optimal för komplex textlayout eller subpixel‑textrendering jämfört med DirectWrite eller moderna textmotorer.

Skrivare och utskrift

En av GDI:s stora styrkor är dess förmåga att rikta samma ritkod mot både skärm och skrivare. Utskriftsdrivrutiner i Windows har historiskt ofta varit GDI‑baserade, vilket möjliggjort att applikationens GDI‑anrop tolkas och översätts till skrivarspecifika instruktioner. Nyare utskriftstekniker som XPS och drivrutiner som använder vektorrendering eller direkt XPS‑stöd minskar dock beroendet av klassiska GDI‑drivrutiner.

Säkerhets- och stabilitetsaspekter

Eftersom GDI‑objekt är resurser som måste hanteras korrekt i applikationer (t.ex. med SelectObject och DeleteObject) är minnes- och resursläckage vanliga felkällor. I multi‑threadade program bör man vara försiktig: Device Contexts och GDI‑objekt är ofta bundna till trådar och fönster, så felaktig användning kan ge race‑conditions eller resurssvält.

Praktiska tips för utvecklare

  • Frigör alltid GDI‑objekt du skapar (penslar, pennor, bitmappar) med lämpliga API‑anrop för att undvika läckor.
  • Använd double buffering (rita först i en minnesbitmap och blit sedan till skärmen) för att undvika flimmer vid uppdateringar.
  • För högre prestanda eller avancerade effekter, överväg Direct2D/Direct3D, OpenGL eller GDI+ beroende på behovet av hårdvaruacceleration och avancerad text/bildhantering.
  • Testa applikationen på olika DPI‑inställningar och skrivare för att säkerställa korrekt skalning och bildkvalitet.

Alternativ och efterföljare

För moderna Windows‑applikationer rekommenderas ofta:

  • Direct2D – hårdvaruaccelererad 2D‑rendering.
  • DirectWrite – modern textrendering och layout.
  • WPF och andra ramverk (t.ex. Skia, Cairo) – erbjuder högre abstraktion och bättre prestanda för vissa typer av applikationer.

Sammantaget är GDI ett stabilt och välbeprövat API för traditionell 2D‑grafik och utskrift i Windows, särskilt lämpligt för enkel grafik och för applikationer där kompatibilitet mot befintliga skrivardrivrutiner är viktigt. För applikationer med höga krav på prestanda, animation eller avancerad text‑ och bildhantering är däremot nyare tekniker ofta bättre val.