效能考慮和最佳做法

本主題提供使用桌面視窗管理員 (DWM) API 的一組最佳做法。

本主題包含下列幾節：

DWM 的應用程式做法

如果您的應用程式處理每英吋的點數 (DPI) 縮放比例，您可以將應用程式宣告為 DPI 感知，並藉由在程式初始化期間設定 DPI 感知旗標或呼叫 SetProcessDPIAware 函式來防止自動調整。

開啟 DWM 組合時，遮蔽的應用程式不會再收到 WM_PAINT 訊息，而且不會要求重新轉譯。每個視窗的內容都已可供撰寫螢幕影像。

最上層 WS_EX_TRANSPARENT 視窗應該結合 WS_EX_LAYERED 樣式，以供點擊測試之用。 WS_EX_TRANSPARENT 在傳統意義中，在沒有重新導向的情況下，對於屬於相同執行緒的視窗階層中的子視窗很有用，但不適用於最上層視窗。

使用區域或分層來建立成形或混合的視窗。請注意，在 Windows Vista 和更新版本的 Windows 中，只有最上層視窗的自訂繪圖部分不會在未繪製的區域提供所需的過時內容。

GetDCOrgEx之類的 API 可用來判斷特定實際值。如果您的裝置內容 (DC) 重新導向視窗， GetDCOrgEx 傳回的原點與畫面上的視窗來源不符。原點會改為是您視窗的背景緩衝區表面原點： (0，0) 。

當所有其他專案都失敗時，請呼叫 DwmSetWindowAttribute 函式來停用視窗轉譯。

避免直接繪製到主要顯示介面。這麼做會強制 DWM 停用組合，直到您的應用程式釋放主要裝置介面為止。

評估您的應用程式是否必須提供自己的雙緩衝處理。 DWM 會有效地雙重緩衝內容，並在單一框架中呈現視窗。

避免讀取或寫入顯示器 DC。雖然 DWM 支援，但我們不建議這麼做，因為效能降低。

避免在非工作區中繪製。雖然應用程式可以存取此區域，但 Microsoft WIN32 API 支援繪圖，但這樣做可能會導致視窗遺失它擁有的任何玻璃框線。

除非不重迭，否則請避免混合 Windows 圖形裝置介面 (GDI) 和 Microsoft DirectX。如果需要混合，請將 GDI 內容繪製到 DirectX 軟體介面，並在撰寫到畫面之前加以結合，或將它們繪製在不同的視窗中。

使用 BitBlt 或 StretchBlt 函式，而不是 Windows GDI+ 來呈現您的繪圖以進行轉譯。 GDI+ 會使用軟體轉譯一次轉譯一條掃描線。這可能會導致應用程式中閃爍。

轉譯模糊後置效果是 CPU 和圖形處理單位的資源密集作業， (GPU) 。應用程式開發人員想要考慮使用工作區模糊的影響，使其不會耗用過多的資源。在下列情況下，您應該特別小心：

當您預期用戶端電腦區域的大小模糊明顯時，即使模糊區域本身不會發生任何更新也一樣。在視窗模糊區域下發生任何更新時，必須轉譯模糊，這會產生 CPU 和 GPU 成本。此外，視窗上的視窗作業 (移動/調整大小/轉換) 將會產生更多成本。
當您在模糊的工作區中預期有重大更新時。這需要在每個更新上重新繪製模糊，並耗用過多的資源。
如果模糊預期涵蓋大量區域，而且也會預期該區域的更新，我們強烈建議您不要模糊工作區。