Confronto tra l'accelerazione hardware di Direct2D e quella di GDI
Direct2D e GDI sono entrambe API di rendering 2D in modalità immediata ed entrambi offrono un certo grado di accelerazione hardware. Questo argomento illustra le differenze tra Direct2D e GDI, incluse le differenze passate e presenti nelle funzionalità di accelerazione hardware di entrambe le API.
Questo argomento include le parti seguenti:
- differenze tra Direct2D e GDI
- Accelerazione hardware di GDI e Direct2D
- Rendering di GDI in Windows 7
- Confronto tra l'accelerazione Direct2D e GDI in Windows 7
- Conclusione
Differenze tra Direct2D e GDI
GDI esegue il rendering di geometrie opache e con alias, ad esempio poligoni, ellissi e linee. Esegue il rendering del testo con alias e ClearType e può supportare la fusione della trasparenza tramite l'API AlphaBlend. Tuttavia, la gestione della trasparenza è incoerente e la maggior parte delle API GDI semplicemente ignora il canale alfa. Poche API GDI garantiscono ciò che il canale alfa conterrà dopo un'operazione. Soprattutto, il rendering di GDI non si adatta facilmente alle operazioni 3D e una GPU moderna esegue il rendering in modo più efficiente nella componente 3D del suo motore di rendering. Ad esempio, linee aliasate di Direct2Dsono progettate per essere implementate semplicemente come due triangoli di cui viene eseguito il rendering sulla GPU, mentre GDI usa l'algoritmo di disegno a linee di Bresenham.
Direct2D esegue il rendering di primitive opache, trasparenti, aliasate e anti-aliasing. Le interfacce utente moderne spesso usano trasparenza e animazione. Direct2D semplifica la creazione di un'interfaccia utente moderna perché offre rigide garanzie su come accetta e esegue il rendering di contenuti trasparenti e il rendering di tutte le primitive viene eseguito usando l'accelerazione hardware. Direct2D non è un superset puro di GDI: primitive che sarebbero state involontariamente lente quando implementate in una GPU non sono presenti in Direct2D. Poiché Direct2D è costruito con questa enfasi sull'accelerazione 3D, è anche facile da usare con Direct3D.
A partire da Windows NT 4, GDI è stato eseguito in modalità kernel. L'applicazione chiama GDI che chiama quindi la sua controparte in modalità kernel che passa le primitive al proprio modello di driver. Questo driver invia quindi i risultati al driver di visualizzazione in modalità kernel globale.
A partire da Windows 2000, GDI e i driver GDI sono stati eseguiti in uno spazio indipendente nel kernel denominato "spazio sessione". Viene creato uno spazio indirizzi di sessione per ogni sessione di accesso e ogni istanza di GDI viene eseguita in modo indipendente in questo spazio di indirizzi in modalità kernel distinto. Direct2D, tuttavia, viene eseguito in modalità utente e passa i comandi di disegno tramite il driver Direct3D in modalità utente al driver in modalità kernel.
Accelerazione hardware GDI e Direct2D
La differenza più importante tra Direct2D e GDI è l'accelerazione hardware e la tecnologia sottostante che li guida. Direct2D è sovrapposto a Direct3D e GDI ha un proprio modello di driver, l'interfaccia DDI (Device Driver Interface) GDI, che corrisponde alle primitive GDI. Il modello di driver Direct3D corrisponde all'hardware di rendering 3D in una GPU. Quando la DDI GDI è stata definita per la prima volta, la maggior parte dell'hardware di accelerazione dello schermo ha come destinazione le primitive GDI. Nel corso del tempo, più enfasi è stata posta sull'accelerazione del gioco 3D e meno sull'accelerazione dell'applicazione. Di conseguenza, l'API BitBlt è stata accelerata dall'hardware, mentre la maggior parte delle altre operazioni GDI non lo erano.
Ciò ha impostato il palcoscenico per una sequenza di modifiche a come GDI viene renderizzato sullo schermo. La figura seguente mostra come il rendering della visualizzazione GDI è cambiato da Windows XP a Windows 7.
Esistono anche diversi fattori aggiuntivi che hanno causato modifiche al modello di driver GDI, come illustrato di seguito.
Aumento della complessità e delle dimensioni dei driver di visualizzazione
I driver 3D sono diventati più complessi nel tempo. Il codice più complesso tende ad avere più difetti, rendendo utile che il driver esista in modalità utente in cui un bug del driver non può causare un riavvio del sistema. Come si può notare nella figura precedente, il driver di visualizzazione è diviso in un componente in modalità utente complesso e un componente in modalità kernel più semplice.
Difficoltà nella sincronizzazione degli spazi di indirizzi della sessione e del kernel globale
In Windows XP esiste un driver di visualizzazione in due spazi di indirizzi diversi: spazio sessione e spazio kernel. Parti del driver devono rispondere a eventi come gli eventi di risparmio energia. Questa operazione deve essere sincronizzata con lo stato del driver nello spazio indirizzi della sessione. Si tratta di un'attività difficile e può causare difetti quando i driver di visualizzazione tentano di gestire questi spazi indirizzi distinti.
Gestione delle finestre composite
Desktop Window Manager (DWM), il gestore finestre di composizione introdotto in Windows 7, esegue il rendering di tutte le finestre su superfici fuori schermo e quindi li compone insieme per essere visualizzati sullo schermo. Questo richiede che GDI possa eseguire il rendering su una superficie che verrà successivamente resa da Direct3D per la visualizzazione. Ciò ha rappresentato un problema nel modello di driver XP, poiché GDI e Direct3D erano stack di driver paralleli.
Di conseguenza, in Windows Vista il driver di visualizzazione GDI DDI è stato implementato come CDD (Canonical Display Driver) fornito da Microsoft, che ha eseguito il rendering del contenuto GDI in una bitmap di memoria di sistema da visualizzare sullo schermo.
Rendering GDI in Windows 7
Il modello di driver usato in Windows Vista richiedeva che ogni finestra di GDI fosse supportata sia da una superficie di memoria video sia da una superficie di memoria di sistema. In questo modo viene usata la memoria di sistema per ogni finestra GDI.
Per questo motivo, GDI è stato modificato di nuovo in Windows 7. Invece di eseguire il rendering in una superficie di memoria di sistema, GDI è stato modificato per eseguire il rendering in un segmento di memoria di apertura. La memoria di apertura può essere aggiornata dalla superficie di memoria video che contiene il contenuto della finestra. GDI può eseguire il rendering nella memoria dell'apertura e il risultato può quindi essere restituito alla superficie della finestra. Poiché il segmento di memoria ad apertura è indirizzabile dalla GPU, la GPU può velocizzare gli aggiornamenti alla superficie della memoria video. Ad esempio, il rendering del testo, BitBlts, AlphaBlend, TransparentBlt e StretchBlt sono tutti accelerati in questi casi.
Contrasto tra l'accelerazione Direct2D e GDI in Windows 7
Direct2D e GDI sono entrambe API di rendering in modalità immediata 2D e sono accelerate dall'hardware. Tuttavia, esistono diverse differenze che rimangono in entrambe le API.
Posizione delle risorse
GDI gestisce le risorse, in particolare le bitmap, nella memoria di sistema per impostazione predefinita. Direct2D mantiene le sue risorse nella memoria video sull'adattatore di visualizzazione. Quando GDI deve aggiornare la memoria video, questa operazione deve essere eseguita sul bus, a meno che la risorsa non si trova già nel segmento di memoria di apertura o se l'operazione può essere espressa direttamente. Al contrario, Direct2D può semplicemente convertire le primitive in primitive Direct3D perché le risorse sono già in memoria video.
Metodo di rendering
Per mantenere la compatibilità, GDI esegue gran parte del rendering nella memoria di apertura utilizzando la CPU. Al contrario, Direct2D converte le chiamate alle sue API in primitive Direct3D e operazioni di disegno. Il rendering del risultato viene quindi eseguito sulla GPU. Parte del rendering di GDI viene eseguito sulla GPU quando la memoria aperta viene copiata sulla superficie di memoria video che rappresenta la finestra GDI.
Scalabilità
le chiamate di rendering di Direct2Dsono tutti flussi di comandi indipendenti alla GPU. Ogni factory Direct2D rappresenta un dispositivo Direct3D diverso. GDI usa un flusso di comandi per tutte le applicazioni nel sistema. Il metodo GDI può comportare un sovraccarico del contesto di rendering della GPU e della CPU.
Ubicazione
Direct2D opera interamente in modalità utente, inclusi il runtime Direct3D e il driver Direct3D in modalità utente. Ciò consente di evitare arresti anomali del sistema causati da difetti del codice nel kernel. GDI, tuttavia, ha la maggior parte delle sue funzionalità nello spazio sessione in modalità kernel, con la relativa superficie API in modalità utente.
Disponibilità dell'accelerazione hardware
GDI è accelerato dall'hardware su Windows XP e su Windows 7 quando Desktop Window Manager è in esecuzione e viene utilizzato un driver WDDM 1.1. Direct2D è accelerato dall'hardware su quasi qualsiasi driver WDDM, indipendentemente dal fatto che DWM sia in uso. In Vista, GDI eseguirà sempre il rendering della CPU.
Modello di presentazione
Quando Windows è stato progettato per la prima volta, c'era memoria insufficiente per consentire l'archiviazione di ogni finestra nella propria bitmap. Di conseguenza, GDI è stato sempre sottoposto a rendering logico direttamente sullo schermo, con varie regioni di ritaglio applicate per garantire che un'applicazione non esegua il rendering fuori dalla sua finestra. Nel modello di Direct2D, un'applicazione esegue il rendering in un buffer nascosto e il risultato viene visualizzato al termine del disegno dell'applicazione. In questo modo Direct2D può gestire scenari di animazione molto più fluida rispetto a GDI.
Conclusione
Il codice GDI esistente continuerà a funzionare correttamente in Windows 7. Tuttavia, quando si scrive nuovo codice di rendering grafico, Direct2D deve essere considerato, perché sfrutta meglio le GPU moderne.