Considerazioni sulle prestazioni e procedure consigliate
Questo argomento presenta un set di procedure consigliate per l'uso delle API Desktop Window Manager (DWM).
In questo argomento sono incluse le sezioni seguenti:
Procedure dell'applicazione per DWM
Se l'applicazione gestisce i punti per pollice (dpi), è possibile dichiarare un'applicazione con riconoscimento dpi e impedire il ridimensionamento automatico impostando il flag con riconoscimento dpi nel manifesto del programma o chiamando la funzione SetProcessDPIAware durante l'inizializzazione del programma.
Con la composizione DWM attivata, le applicazioni oscurate non ricevono più messaggi WM_PAINT e non vengono richieste di nuovo il rendering. Il contenuto di ogni finestra è già disponibile per comporre l'immagine dello schermo.
Le finestre di WS_EX_TRANSPARENT di primo livello devono essere combinate con uno stile WS_EX_LAYERED ai fini del hit testing. WS_EX_TRANSPARENT nel senso classico, senza reindirizzamento, è utile per le finestre figlio in una gerarchia di finestre che appartengono allo stesso thread, ma non è destinato a finestre di primo livello.
Usare aree o livelli per creare finestre a forma o combinate. Si noti che in Windows Vista e versioni successive di Windows, il disegno personalizzato solo parte di una finestra di primo livello non fornirà il contenuto non aggiornato desiderato in aree non ritirate.
Le API, ad esempio GetDCOrgEx , possono essere usate per determinare determinati valori effettivi. Se si dispone di un contesto del dispositivo (DC) per una finestra reindirizzata, l'origine restituita da GetDCOrgEx non corrisponderà all'origine della finestra sullo schermo. L'origine sarà invece l'origine della superficie back-buffer per la finestra: (0, 0, 0).
Quando tutto il resto ha esito negativo, disabilitare il rendering della finestra chiamando la funzione DwmSetWindowAttribute .
Procedure di disegno per DWM
Evitare di disegnare direttamente nell'area di visualizzazione primaria. In questo modo il DWM forza la composizione per disabilitare la composizione fino a quando l'applicazione rilascia l'area del dispositivo primario.
Valutare se l'applicazione deve fornire un buffer doppio. Il contenuto del DWM raddoppia efficacemente i buffer e presenta la finestra in un singolo frame.
Evitare di leggere o scrivere in un controller di dominio di visualizzazione. Anche se supportato da DWM, non è consigliabile a causa di prestazioni ridotte.
Evitare di disegnare nell'area non client. Anche se questa area può essere accessibile dall'applicazione e il disegno è supportato dall'API Microsoft Win32, in questo modo la finestra può perdere qualsiasi bordo di vetro.
Evitare di combinare Windows Graphics Device Interface (GDI) e Microsoft DirectX a meno che non si sovrapponga. Se la combinazione è necessaria, disegnare il contenuto GDI in un'area software DirectX e combinarli prima di comporre lo schermo oppure disegnareli in finestre separate.
Usare la funzione BitBlt o StretchBlt anziché Windows GDI+ per presentare il disegno per il rendering. GDI+ esegue il rendering di una riga di analisi alla volta con il rendering software. Ciò può causare un flickering nelle applicazioni.
DWM Blur-Behind Area client
Il rendering dell'effetto blur-behind è un'operazione a elevato utilizzo di risorse sia per la CPU che per l'unità di elaborazione grafica (GPU). Gli sviluppatori di applicazioni sono invitati a considerare le implicazioni dell'uso del blur dell'area client in modo che non usi risorse eccessive. È consigliabile usare particolare attenzione nei casi seguenti:
- Quando si prevede che le dimensioni del blur dell'area client siano significative, anche se non si verificheranno aggiornamenti nell'area sfocata stessa. Il blur deve essere eseguito nel caso in cui gli aggiornamenti si verifichino sotto l'area sfocata della finestra, che comporta costi cpu e GPU. Inoltre, le operazioni delle finestre nella finestra (sposta/ridimensiona/transizioni) comportano più costi.
- Quando si prevede aggiornamenti significativi nell'area client sfocata. Ciò richiederà un'analisi del blur in ogni aggiornamento e utilizzerà risorse eccessive.
- Se si prevede che il blur coprisse un'area significativa e gli aggiornamenti a tale area siano previsti, è consigliabile non sfuare l'area client.