Condividi tramite

Confronto tra Accelerazione hardware Direct2D e GDI

  • Articolo

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.

In questo argomento sono riportate le parti seguenti:

Differenze tra Direct2D e GDI

GDI esegue il rendering di geometrie opache con alias, ad esempio poligoni, puntini di sospensione 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 ignora semplicemente il canale alfa. Poche API GDI garantiscono ciò che il canale alfa conterrà dopo un'operazione. In particolare, il rendering di GDI non esegue facilmente il mapping alle operazioni 3D e un rendering gpu moderno esegue il rendering più efficiente nella parte 3D del motore di rendering. Ad esempio, le linee con alias Direct2D sono progettate per essere implementate semplicemente come due triangoli sottoposti a rendering sulla GPU, mentre GDI usa l'algoritmo di disegno a linee di Bresenham.

Direct2D esegue il rendering di primitive opache, trasparenti, con alias e anti-aliasing. Le interfacce utente moderne spesso usano trasparenza e animazione. Direct2D semplifica la creazione di un'interfaccia utente moderna perché offre garanzie rigorose sul modo in cui accetta e esegue il rendering di contenuto trasparente 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 è in esecuzione 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 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.

figura 1 - direct2d rispetto a gdi

Accelerazione hardware GDI e Direct2D

La differenza più importante tra l'accelerazione hardware Direct2D e GDI è 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, è stata posta più enfasi sull'accelerazione del gioco 3D e meno sull'accelerazione dell'applicazione. Di conseguenza, l'API BitBlt è stata accelerata dall'hardware e la maggior parte delle altre operazioni GDI non erano.

In questo modo viene impostata la fase per una sequenza di modifiche alla modalità di rendering dell'interfaccia GDI nella visualizzazione. La figura seguente mostra come il rendering della visualizzazione GDI è cambiato da Windows XP a Windows 7.

figura 2 - Evoluzione del rendering dello schermo gdi

Sono stati inoltre rilevati 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 vantaggioso l'esistenza del driver 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 indirizzi della sessione e del kernel globale

In Windows XP esiste un driver di visualizzazione in due spazi 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 in superfici fuori schermo e quindi li compone insieme per essere visualizzati sullo schermo. Ciò richiede che GDI sia in grado di eseguire il rendering in una superficie che verrà quindi sottoposta a rendering 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 DDI GDI è 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 comporre sullo schermo.

Rendering GDI in Windows 7

Il modello di driver usato in Windows Vista richiede che ogni finestra GDI sia supportata da una superficie di memoria video che da una superficie di memoria di sistema. Ciò ha comportato l'uso della memoria di sistema per ogni finestra GDI.

Per questo motivo, GDI è stato modificato di nuovo in Windows 7. Anziché 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 dall'area 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 all'area della finestra. Poiché il segmento di memoria aperture è indirizzabile dalla GPU, la GPU può accelerare questi aggiornamenti alla superficie di memoria video. Ad esempio, il rendering del testo, BitBlts, AlphaBlend, TransparentBlt e StretchBlt sono tutti accelerati in questi casi.

Contrasto dell'accelerazione Direct2D e GDI in Windows 7

Direct2D e GDI sono entrambe API di rendering in modalità immediata 2D e sono accelerate dall'hardware. Esistono tuttavia alcune 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 gestisce le risorse in memoria video nella scheda 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 aperture 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 per aprire la memoria usando la CPU. Al contrario, Direct2D converte le relative chiamate API in primitive Direct3D e operazioni di disegno. Il rendering del risultato viene quindi eseguito sulla GPU. Il rendering di GDI viene eseguito sulla GPU quando la memoria di apertura viene copiata nell'area di memoria video che rappresenta la finestra GDI.

Scalabilità

Le chiamate di rendering di Direct2D sono 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 una compilazione del sovraccarico del contesto di rendering della GPU e della CPU.

Posizione

Direct2D opera interamente in modalità utente, tra cui 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 è hardware accelerato in Windows XP e accelerato in Windows 7 quando Desktop Window Manager è in esecuzione e un driver WDDM 1.1 è in uso. Direct2D è l'hardware accelerato su quasi tutti i driver WDDM e 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, memoria insufficiente per consentire l'archiviazione di ogni finestra nella propria bitmap. Di conseguenza, GDI ha sempre eseguito il rendering logico direttamente sullo schermo, con varie aree di ritaglio applicate per garantire che un'applicazione non sia stata eseguita il rendering all'esterno della finestra. Nel modello Direct2D viene eseguito il rendering di un'applicazione in un buffer back-buffer e il risultato viene visualizzato al termine del disegno dell'applicazione. Ciò consente a Direct2D di gestire gli scenari di animazione molto più fluidamente che 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.