Panoramica di DXGI
Microsoft DirectX Graphics Infrastructure (DXGI) riconosce che alcune parti della grafica si evolveno più lentamente di altre. L'obiettivo principale di DXGI è gestire attività di basso livello che possono essere indipendenti dal runtime di grafica DirectX. DXGI fornisce un framework comune per i componenti grafici futuri; il primo componente che sfrutta DXGI è Microsoft Direct3D 10.
Nelle versioni precedenti di Direct3D, le attività a basso livello, ad esempio l'enumerazione dei dispositivi hardware, la presentazione di frame sottoposti a rendering in un output, il controllo di gamma e la gestione di una transizione a schermo intero sono stati inclusi nel runtime Direct3D. Queste attività sono ora implementate in DXGI.
Lo scopo di DXGI è comunicare con il driver in modalità kernel e l'hardware di sistema, come illustrato nel diagramma seguente.
Un'applicazione può accedere direttamente a DXGI o chiamare direttamente le API Direct3D in D3D11_1.h, D3D11.h, D3D10_1.h o D3D10.h, che gestisce le comunicazioni con DXGI per l'utente. È possibile usare DXGI direttamente se l'applicazione deve enumerare i dispositivi o controllare la modalità di presentazione dei dati a un output.
In questo argomento sono contenute le sezioni seguenti.
- Enumerazione di adapter
- Presentazione
- Creare una catena di scambio
- Cura e alimentazione della catena di scambio
- Ridimensionamento finestra di gestione
- Scelta dell'output e delle dimensioni DXGI
- Debug in modalità Full-Screen
- Distruggere una catena di scambio
- Uso di un monitoraggio ruotato
- Modalità di cambio
- Suggerimento prestazioni schermo intero
- Considerazioni su multithread
- Risposte DXGI da DLLMain
- Modifiche a DXGI 1.1
- Modifiche a DXGI 1.2
- Argomenti correlati
Per vedere quali formati sono supportati dall'hardware Direct3D 11:
- Supporto del formato DXGI per l'hardware Direct3D Livello di funzionalità 12.1
- Supporto del formato DXGI per l'hardware a livello di funzionalità Direct3D 12.0
- Supporto del formato DXGI per l'hardware Direct3D Livello di funzionalità 11.1
- Supporto del formato DXGI per l'hardware Direct3D a livello di funzionalità 11.0
- Supporto hardware per formati Direct3D 10Level9
- Supporto hardware per formati Direct3D 10.1
- Supporto hardware per formati Direct3D 10
Enumerazione degli adattatori
Un adattatore è un'astrazione dell'hardware e della funzionalità software del computer. Nel computer sono in genere presenti molti adattatori. Alcuni dispositivi vengono implementati nell'hardware (ad esempio la scheda video) e alcuni vengono implementati nel software (ad esempio il rasterizzatore di riferimento Direct3D). Gli adattatori implementano funzionalità usate da un'applicazione grafica. Il diagramma seguente mostra un sistema con un singolo computer, due adattatori (schede video) e tre monitor di output.
Quando si enumerazione di queste parti di hardware, DXGI crea un'interfaccia IDXGIOutput1 per ogni output (o monitor) e un'interfaccia IDXGIAdapter2 per ogni scheda video (anche se è una scheda video incorporata in una scheda madre). L'enumerazione viene eseguita usando una chiamata di interfaccia IDXGIFactory, IDXGIFactory::EnumAdapters, per restituire un set di interfacce IDXGIAdapter che rappresentano l'hardware video.
DXGI 1.1 ha aggiunto l'interfaccia IDXGIFactory1 . IDXGIFactory1::EnumAdapters1 restituisce un set di interfacce IDXGIAdapter1 che rappresentano l'hardware video.
Se si desidera selezionare funzionalità hardware video specifiche quando si usano API Direct3D, è consigliabile chiamare in modo iterativo la funzione D3D11CreateDevice o D3D11CreateDeviceAndSwapChain con ogni handle di scheda e possibile livello di funzionalità hardware. Questa funzione ha esito positivo se il livello di funzionalità è supportato dall'adattatore specificato.
Nuove informazioni sull'enumerazione degli adattatori per Windows 8
A partire da Windows 8, è sempre presente un adattatore denominato "Microsoft Basic Render Driver". Questa scheda include un VendorId di 0x1414 e un DeviceID di 0x8c. Questa scheda ha anche il valore DXGI_ADAPTER_FLAG_SOFTWARE impostato nel membro Flag della relativa struttura DXGI_ADAPTER_DESC2 . Questa scheda è un dispositivo di sola rendering senza output di visualizzazione. DXGI non restituisce mai DXGI_ERROR_DEVICE_REMOVED per questa scheda.
Se il driver di visualizzazione di un computer non funziona o è disabilitato, l'adattatore primario (NULL) del computer potrebbe essere chiamato anche "Microsoft Basic Render Driver". Tuttavia, questa scheda ha output e non ha il valore DXGI_ADAPTER_FLAG_SOFTWARE impostato. Per impostazione predefinita, il sistema operativo e le app usano questa scheda. Se un driver di visualizzazione è installato o abilitato, le app possono ricevere DXGI_ERROR_DEVICE_REMOVED per questa scheda e quindi devono rinumerare gli adattatori.
Quando una scheda di visualizzazione primaria di un computer è la scheda di visualizzazione "Adattatore display di base Microsoft" (WARP ), tale computer ha anche una seconda scheda. Questa seconda scheda è il dispositivo di sola rendering che non ha output di visualizzazione e per cui DXGI non restituisce mai DXGI_ERROR_DEVICE_REMOVED.
Se si vuole usare WARP per il rendering, il calcolo o altre attività a esecuzione prolungata, è consigliabile usare il dispositivo di sola rendering. È possibile ottenere un puntatore al dispositivo di sola rendering chiamando il metodo IDXGIFactory1::EnumAdapters1 . Si crea anche il dispositivo di sola rendering quando si specifica D3D_DRIVER_TYPE_WARP nel parametro DriverType di D3D11CreateDevice perché il dispositivo WARP usa anche l'adattatore WARP di sola rendering.
Presentazione
Il processo dell'applicazione consiste nel eseguire il rendering dei frame e chiedere a DXGI di presentare tali fotogrammi all'output. Se l'applicazione ha due buffer disponibili, può eseguire il rendering di un buffer durante la presentazione di un altro. L'applicazione potrebbe richiedere più di due buffer a seconda del tempo necessario per eseguire il rendering di un frame o della frequenza di fotogrammi desiderata per la presentazione. Il set di buffer creati viene chiamato una catena di scambio, come illustrato di seguito.
- Creare una catena di scambio
- Cura e alimentazione della catena di scambio
- Ridimensionamento finestra di gestione
- Scelta dell'output e delle dimensioni DXGI
- Debug in modalità Full-Screen
- Distruggere una catena di scambio
- Uso di un monitoraggio ruotato
- Modalità di cambio
- Suggerimento prestazioni schermo intero
- Considerazioni su multithread
Una catena di scambio ha un buffer anteriore e uno o più buffer indietro. Ogni applicazione crea una propria catena di scambio. Per ottimizzare la velocità della presentazione dei dati in un output, una catena di scambio viene quasi sempre creata nella memoria di un sub-system di visualizzazione, illustrata nella figura seguente.
Il sotto-sistema di visualizzazione (che spesso è una scheda video ma può essere implementato su una scheda madre) contiene una GPU, un convertitore digitale a analogico (DAC) e memoria. La catena di scambio viene allocata all'interno di questa memoria per rendere la presentazione molto veloce. Il sub-system di visualizzazione presenta i dati nel buffer anteriore all'output.
Una catena di scambio è configurata per disegnare in modalità a schermo intero o a finestra, questo elimina la necessità di sapere se un output è finestrato o schermo intero. Una catena di scambio in modalità schermo intero può ottimizzare le prestazioni modificando la risoluzione dello schermo.
Creare la catena di scambio
Differenze tra Direct3D 9 e Direct3D 10: Direct3D 10 è il primo componente grafico da usare DXGI. DXGI ha alcuni diversi comportamenti della catena di scambio.
|
I buffer di una catena di scambio vengono creati a una determinata dimensione e in un formato specifico. L'applicazione specifica questi valori (oppure è possibile ereditare le dimensioni dalla finestra di destinazione) all'avvio e può quindi modificarli facoltativamente quando le dimensioni della finestra cambiano in risposta agli eventi di input o programma dell'utente.
Dopo aver creato la catena di scambio, in genere si vuole eseguire il rendering delle immagini. Ecco un frammento di codice che configura un contesto Direct3D per il rendering in una catena di scambio. Questo codice estrae un buffer dalla catena di scambio, crea una visualizzazione di destinazione di rendering da tale buffer, quindi la imposta nel dispositivo:
ID3D11Resource * pBB;
ThrowFailure( pSwapChain->GetBuffer(0, __uuidof(pBB),
reinterpret_cast<void**>(&pBB)), "Couldn't get back buffer");
ID3D11RenderTargetView * pView;
ThrowFailure( pD3D11Device->CreateRenderTargetView(pBB, NULL, &pView),
"Couldn't create view" );
pD3D11DeviceContext->OMSetRenderTargets(1, &pView, 0);
Dopo il rendering di un frame in un buffer della catena di scambio, chiamare IDXGISwapChain1::P resent1. L'applicazione può quindi eseguire il rendering dell'immagine successiva.
Cura e alimentazione della catena di scambio
Dopo aver eseguito il rendering dell'immagine, chiamare IDXGISwapChain1::P resent1 ed eseguire il rendering dell'immagine successiva. Questo è l'entità della vostra responsabilità.
Se in precedenza è stato chiamato IDXGIFactory::MakeWindowAssociation, l'utente può premere la combinazione di tasti Alt-Enter e DXGI eseguirà la transizione dell'applicazione tra la modalità finestra e a schermo intero. IDXGIFactory::MakeWindowAssociation è consigliato, perché è fortemente desiderato un meccanismo di controllo standard per l'utente.
Anche se non è necessario scrivere più codice di quanto sia stato descritto, alcuni semplici passaggi possono rendere l'applicazione più reattiva. La considerazione più importante è il ridimensionamento dei buffer della catena di scambio in risposta al ridimensionamento della finestra di output. Naturalmente, la route migliore dell'applicazione consiste nel rispondere alle WM_SIZE e chiamare IDXGISwapChain::ResizeBuffers, passando le dimensioni contenute nei parametri del messaggio. Questo comportamento rende ovviamente l'applicazione in grado di rispondere bene all'utente quando trascina i bordi della finestra, ma è anche esattamente ciò che consente una transizione a schermo intero senza problemi. La finestra riceverà un messaggio WM_SIZE ogni volta che si verifica una transizione di questo tipo e la chiamata di IDXGISwapChain::ResizeBuffers è la possibilità della catena di scambio di allocare nuovamente l'archiviazione dei buffer per una presentazione ottimale. Questo è il motivo per cui l'applicazione è necessaria per rilasciare tutti i riferimenti presenti nei buffer esistenti prima di chiamare IDXGISwapChain::ResizeBuffers.
Non è possibile chiamare IDXGISwapChain::ResizeBuffers in risposta al passaggio alla modalità a schermo intero (più naturalmente, in risposta a WM_SIZE), può impedire l'ottimizzazione del capovolgimento, in cui DXGI può semplicemente scambiare il buffer visualizzato, anziché copiare i dati di un intero schermo.
IDXGISwapChain1::P resent1 ti informerà se la finestra di output è completamente occlusa tramite DXGI_STATUS_OCCLUDED. In questo caso, è consigliabile che l'applicazione entri in modalità standby (chiamando IDXGISwapChain1::P resent1 con DXGI_PRESENT_TEST) perché le risorse usate per eseguire il rendering del frame vengono sprecate. L'uso di DXGI_PRESENT_TEST impedisce la presentazione di dati durante l'esecuzione del controllo dell'occlusione. Quando IDXGISwapChain1::P resent1 restituisce S_OK, è consigliabile uscire dalla modalità standby; non usare il codice restituito per passare alla modalità standby perché in questo modo la catena di scambio non è in grado di rinunciare alla modalità schermo intero.
Il runtime Direct3D 11.1, disponibile a partire da Windows 8, fornisce una catena di scambio di modelli capovolto, ovvero una catena di scambio con il valore DXGI_SWAP_EFFECT_FLIP_SEQUENTIAL impostato nel membro SwapEffect di DXGI_SWAP_CHAIN_DESC o DXGI_SWAP_CHAIN_DESC1. Quando si presentano fotogrammi a un output con una catena di scambio del modello flip-model, DXGI annulla l'associazione del buffer nascosto da tutte le posizioni dello stato della pipeline, ad esempio una destinazione di rendering della fusione di output, che esegue il writeback del buffer 0. È quindi consigliabile chiamare ID3D11DeviceContext::OMSetRenderTargets immediatamente prima di eseguire il rendering nel buffer nascosto. Ad esempio, non chiamare OMSetRenderTargets e quindi eseguire operazioni di compute shader che non finiscono per il rendering nella risorsa. Per altre info sulle catene di scambio di modelli flip-model e sui relativi vantaggi, vedi DXGI Flip Model.
Nota
In Direct3D 10 e Direct3D 11 non è necessario chiamare IDXGISwapChain::GetBuffer per recuperare il buffer nascosto 0 dopo aver chiamato IDXGISwapChain1::P resent1 perché per praticità le identità dei buffer nascosto cambiano. Questa situazione non si verifica in Direct3D 12 e l'applicazione deve invece tenere traccia manualmente degli indici del buffer nascosto.
Gestione del ridimensionamento delle finestre
È possibile usare il metodo IDXGISwapChain::ResizeBuffers per gestire il ridimensionamento delle finestre. Prima di chiamare ResizeBuffers, è necessario rilasciare tutti i riferimenti in sospeso ai buffer della catena di scambio. L'oggetto che in genere contiene un riferimento al buffer di una catena di scambio è una visualizzazione di destinazione di rendering.
Il codice di esempio seguente mostra come chiamare ResizeBuffers dall'interno del gestore WindowProc per WM_SIZE messaggi:
case WM_SIZE:
if (g_pSwapChain)
{
g_pd3dDeviceContext->OMSetRenderTargets(0, 0, 0);
// Release all outstanding references to the swap chain's buffers.
g_pRenderTargetView->Release();
HRESULT hr;
// Preserve the existing buffer count and format.
// Automatically choose the width and height to match the client rect for HWNDs.
hr = g_pSwapChain->ResizeBuffers(0, 0, 0, DXGI_FORMAT_UNKNOWN, 0);
// Perform error handling here!
// Get buffer and create a render-target-view.
ID3D11Texture2D* pBuffer;
hr = g_pSwapChain->GetBuffer(0, __uuidof( ID3D11Texture2D),
(void**) &pBuffer );
// Perform error handling here!
hr = g_pd3dDevice->CreateRenderTargetView(pBuffer, NULL,
&g_pRenderTargetView);
// Perform error handling here!
pBuffer->Release();
g_pd3dDeviceContext->OMSetRenderTargets(1, &g_pRenderTargetView, NULL );
// Set up the viewport.
D3D11_VIEWPORT vp;
vp.Width = width;
vp.Height = height;
vp.MinDepth = 0.0f;
vp.MaxDepth = 1.0f;
vp.TopLeftX = 0;
vp.TopLeftY = 0;
g_pd3dDeviceContext->RSSetViewports( 1, &vp );
}
return 1;
Scelta dell'output e delle dimensioni DXGI
Per impostazione predefinita, DXGI sceglie l'output che contiene la maggior parte dell'area client della finestra. Questa è l'unica opzione disponibile per DXGI quando passa a schermo intero in risposta a alt-invio. Se l'applicazione sceglie di passare alla modalità a schermo intero da sola, può chiamare IDXGISwapChain::SetFullscreenState e passare un IDXGIOutput1 esplicito (o NULL, se l'applicazione è felice di consentire a DXGI di decidere).
Per ridimensionare l'output durante lo schermo intero o la finestra, è consigliabile chiamare IDXGISwapChain::ResizeTarget, poiché questo metodo ridimensiona anche la finestra di destinazione. Poiché la finestra di destinazione viene ridimensionata, il sistema operativo invia WM_SIZE e il codice chiamerà naturalmente IDXGISwapChain::ResizeBuffers in risposta. Si tratta quindi di uno spreco di sforzi per ridimensionare i buffer e quindi ridimensionare successivamente la destinazione.
Debug in modalità schermo intero
Una catena di scambio DXGI abbandona la modalità schermo intero solo quando è assolutamente necessario. Ciò significa che è possibile eseguire il debug di un'applicazione a schermo intero usando più monitor, purché la finestra di debug non si sovrapponga alla finestra di destinazione della catena di scambio. In alternativa, è possibile impedire completamente il cambio di modalità non impostando il flag di DXGI_SWAP_CHAIN_FLAG_ALLOW_MODE_SWITCH .
Se il cambio di modalità è consentito, una catena di scambio rinuncerà alla modalità a schermo intero ogni volta che la finestra di output viene bloccata da un'altra finestra. Il controllo dell'occlusione viene eseguito durante IDXGISwapChain1::P resent1 o da un thread separato il cui scopo è watch per verificare se l'applicazione non risponde e non chiama più IDXGISwapChain1::P resent1). Per disabilitare la capacità del thread separato di causare un'opzione, impostare la chiave del Registro di sistema seguente su qualsiasi valore diverso da zero.
HKCU\Software\Microsoft\DXGI\DisableFullscreenWatchdog
Eliminazione di una catena di scambio
È possibile che non venga rilasciata una catena di scambio in modalità schermo intero, perché in questo modo è possibile creare conflitti di thread (che causeranno la generazione di un'eccezione non continuabile da parte di DXGI). Prima di rilasciare una catena di scambio, passare prima alla modalità finestra (usando IDXGISwapChain::SetFullscreenState( FALSE, NULL )) e quindi chiamare IUnknown::Release.
Uso di un monitor ruotato
Un'applicazione non deve preoccuparsi dell'orientamento del monitoraggio, DXGI ruota un buffer della catena di scambio durante la presentazione, se necessario. Naturalmente, questa rotazione aggiuntiva può influire sulle prestazioni. Per ottenere prestazioni ottimali, prendersi cura della rotazione nell'applicazione eseguendo le operazioni seguenti:
- Usare il DXGI_SWAP_CHAIN_FLAG_NONPREROTATED. Questo notifica a DXGI che l'applicazione produrrà un'immagine ruotata (ad esempio, modificando la relativa matrice di proiezione). Una cosa da notare, questo flag è valido solo in modalità schermo intero.
- Allocare ogni buffer della catena di scambio nella dimensione ruotata. Usare IDXGIOutput::GetDesc per ottenere questi valori, se necessario.
Eseguendo la rotazione nell'applicazione, DXGI eseguirà semplicemente una copia anziché una copia e una rotazione.
Il runtime Direct3D 11.1, disponibile a partire da Windows 8, fornisce una catena di scambio di modelli capovolgimento( ovvero una catena di scambio con il valore DXGI_SWAP_EFFECT_FLIP_SEQUENTIAL impostato nel membro SwapEffect di DXGI_SWAP_CHAIN_DESC1). Per ottimizzare le ottimizzazioni della presentazione disponibili con una catena di scambio di modelli capovolto, è consigliabile impostare il contenuto per orientare il contenuto in modo che corrisponda all'output specifico in cui risiede il contenuto quando tale contenuto occupa completamente l'output. Per altre info sulle catene di scambio di modelli flip-model e sui relativi vantaggi, vedi DXGI Flip Model.
Modalità di commutazione
La catena di scambio DXGI potrebbe modificare la modalità di visualizzazione di un output durante la transizione a schermo intero. Per abilitare la modifica della modalità di visualizzazione automatica, è necessario specificare DXGI_SWAP_CHAIN_FLAG_ALLOW_MODE_SWITCH nella descrizione della catena di scambio. Se la modalità di visualizzazione cambia automaticamente, DXGI sceglierà la modalità più modesta (le dimensioni e la risoluzione non cambieranno, ma la profondità del colore potrebbe). Il ridimensionamento dei buffer della catena di scambio non causa un cambio di modalità. La catena di scambio fa una promessa implicita che se si sceglie un buffer nascosto che corrisponde esattamente a una modalità di visualizzazione supportata dall'output di destinazione, passerà alla modalità di visualizzazione quando si entra in modalità schermo intero su tale output. Di conseguenza, scegli una modalità di visualizzazione scegliendo le dimensioni e il formato del buffer nascosto.
Suggerimento per le prestazioni a schermo intero
Quando chiami IDXGISwapChain1::P resent1 in un'applicazione a schermo intero, la catena di scambio capovolge il contenuto del buffer nascosto nel buffer anteriore. Ciò richiede che la catena di scambio sia stata creata usando una modalità di visualizzazione enumerata (specificata in DXGI_SWAP_CHAIN_DESC1). Se non si enumera le modalità di visualizzazione o si specifica erroneamente la modalità di visualizzazione nella descrizione, la catena di scambio può eseguire invece un trasferimento bit-block (bitblt). Il bitblt causa un'estensione aggiuntiva della copia, oltre ad un aumento dell'utilizzo della memoria video ed è difficile da rilevare. Per evitare questo problema, enumerare le modalità di visualizzazione e inizializzare correttamente la descrizione della catena di scambio prima di creare la catena di scambio. Ciò garantisce prestazioni massime quando si capovolge in modalità schermo intero ed evitare il sovraccarico di memoria aggiuntivo.
Considerazioni sul multithread
Quando si usa DXGI in un'applicazione con più thread, è necessario prestare attenzione per evitare di creare un deadlock, in cui due thread diversi sono in attesa l'uno sull'altro per completare. Esistono due situazioni in cui ciò può verificarsi.
- Il thread di rendering non è il thread message-pump.
- Il thread che esegue un'API DXGI non è lo stesso thread che ha creato la finestra.
Prestare attenzione che non si abbia mai l'attesa del thread message-pump sul thread di rendering quando si usano catene di scambio a schermo intero. Ad esempio, la chiamata a IDXGISwapChain1::P resent1 (dal thread di rendering) può causare l'attesa del thread di rendering sul thread message-pump. Quando si verifica una modifica della modalità, questo scenario è possibile se Present1 chiama ::SetWindowPos() o ::SetWindowStyle() e uno di questi metodi chiama ::SendMessage(). In questo scenario, se il thread message-pump ha una sezione critica che lo protegge o se il thread di rendering è bloccato, i due thread verranno deadlock.
Per altre info sull'uso di DXGI con più thread, vedi Multithreading e DXGI.
Risposte DXGI da DLLMain
Poiché una funzione DllMain non può garantire l'ordine in cui carica e scarica le DLL, è consigliabile che la funzione DllMain dell'app non chiami funzioni o metodi Direct3D o DXGI, incluse funzioni o metodi che creano o rilasciano oggetti. Se la funzione DllMain dell'app chiama un determinato componente, tale componente potrebbe chiamare un'altra DLL non presente nel sistema operativo, che causa l'arresto anomalo del sistema operativo. Direct3D e DXGI potrebbero caricare un set di DLL, in genere un set di driver, che differisce dal computer al computer. Pertanto, anche se l'app non si arresta in modo anomalo nei computer di sviluppo e test quando la sua funzione DllMain chiama funzioni o metodi Direct3D o DXGI, potrebbe arrestarsi in modo anomalo quando viene eseguito in un altro computer.
Per impedire la creazione di un'app che potrebbe causare l'arresto anomalo del sistema operativo, DXGI fornisce le risposte seguenti nelle situazioni specificate:
- Se la funzione DllMain dell'app rilascia l'ultimo riferimento a una factory DXGI, DXGI genera un'eccezione.
- Se la funzione DllMain dell'app crea una factory DXGI, DXGI restituisce un codice di errore.
Modifiche a DXGI 1.1
In DXGI 1.1 sono state aggiunte le funzionalità seguenti.
Supporto delle superfici condivise sincronizzate
Le superfici condivise sincronizzate per Direct3D 10.1 e Direct3D 11 consentono una condivisione efficiente della superficie di lettura e scrittura tra più dispositivi Direct3D (la condivisione tra dispositivi Direct3D 10 e Direct3D 11 è possibile). Vedere IDXGIKeyedMutex::AcquireSync e IDXGIKeyedMutex::ReleaseSync.
Supporto colori alti
Supporta il formato DXGI_FORMAT_R10G10B10_XR_BIAS_A2_UNORM.
IDXGIDevice1::SetMaximumFrameLatency e IDXGIDevice1::GetMaximumFrameLatency
IDXGIFactory1::EnumAdapters1 enumera schede locali senza monitoraggi o output collegati, nonché schede con output collegati. La prima scheda restituita sarà la scheda locale in cui viene visualizzata la replica primaria desktop.
Supporto del formato BGRA
DXGI_FORMAT_B8G8R8A8_UNORM e DXGI_FORMAT_B8G8R8A8_UNORM_SRGB, vedere IDXGISurface1::GetDC e IDXGISurface1::ReleaseDC.
Modifiche a DXGI 1.2
In DXGI 1.2 sono state aggiunte le funzionalità seguenti.
- Catena di scambio stereo
- Catena di scambio di modelli capovolti
- Presentazione ottimizzata (scorrimento, rettangoli sporchi e rotazione)
- Risorse condivise e sincronizzazione migliorate
- Duplicazione desktop
- Uso ottimizzato della memoria video
- Supporto per formati a 16 bit per pixel (bpp) (DXGI_FORMAT_B5G6R5_UNORM, DXGI_FORMAT_B5G5R5A1_UNORM, DXGI_FORMAT_B4G4R4A4_UNORM)
- API di debug
Per altre info su DXGI 1.2, vedi Miglioramenti di DXGI 1.2.
Argomenti correlati
Commenti e suggerimenti
Presto disponibile: Nel corso del 2024 verranno gradualmente disattivati i problemi di GitHub come meccanismo di feedback per il contenuto e ciò verrà sostituito con un nuovo sistema di feedback. Per altre informazioni, vedere https://aka.ms/ContentUserFeedback.
Invia e visualizza il feedback per