Freigeben über


Überlegungen zur Leistung und bewährte Methoden

In diesem Thema werden eine Reihe bewährter Methoden für die Verwendung der DESKTOP WINDOW Manager-APIs (DWM) vorgestellt.

Dieses Thema enthält folgende Abschnitte:

Anwendungsmethoden für DWM

Wenn Ihre Anwendung die Dpi-Skalierung (Dots per Inch) verarbeitet, können Sie eine Anwendung als dpi-fähig deklarieren und die automatische Skalierung verhindern, indem Sie das dpi-fähige Flag im Manifest des Programms festlegen oder die SetProcessDPIAware-Funktion während der Programminitialisierung aufrufen.

Wenn die DWM-Komposition aktiviert ist, erhalten verdeckte Anwendungen keine WM_PAINT Nachrichten mehr und werden nicht zum erneuten Rendern aufgefordert. Der Inhalt jedes Fensters ist bereits verfügbar, um das Bildschirmbild zu verfassen.

WS_EX_TRANSPARENT Fenster der obersten Ebene sollten für Treffertests mit einem WS_EX_LAYERED-Stil kombiniert werden. WS_EX_TRANSPARENT im klassischen Sinne ohne Umleitung ist für untergeordnete Fenster in einer Hierarchie von Fenstern nützlich, die zum gleichen Thread gehören, aber nicht für Fenster der obersten Ebene vorgesehen sind.

Verwenden Sie Regionen oder Ebenen, um geformte oder gemischte Fenster zu erstellen. Beachten Sie, dass in Windows Vista und höheren Versionen von Windows benutzerdefinierte Zeichnung nur ein Teil eines Fensters der obersten Ebene nicht den gewünschten veralteten Inhalt in nicht erstellten Regionen bereitstellt.

APIs wie GetDCOrgEx können verwendet werden, um bestimmte tatsächliche Werte zu bestimmen. Wenn Sie über einen Gerätekontext (DC) für ein umgeleitetes Fenster verfügen, stimmt der von GetDCOrgEx zurückgegebene Ursprung nicht mit dem Ursprung Ihres Fensters auf dem Bildschirm überein. Der Ursprung ist stattdessen der Ursprung der Hintergrundpufferoberfläche für Ihr Fenster: (0, 0).

Wenn alles andere fehlschlägt, deaktivieren Sie das Fensterrendering, indem Sie die DwmSetWindowAttribute-Funktion aufrufen.

Zeichnungsmethoden für DWM

Vermeiden Sie es, direkt auf die primäre Anzeigeoberfläche zu zeichnen. Auf diese Weise wird erzwungen, dass die DWM die Komposition deaktiviert, bis Ihre Anwendung die primäre Geräteoberfläche freigibt.

Bewerten Sie, ob Ihre Anwendung eine eigene doppelte Pufferung bereitstellen muss. Der DWM puffert inhalte effektiv doppelt und stellt das Fenster in einem einzelnen Frame dar.

Vermeiden Sie das Lesen von oder Schreiben in einen Anzeige-DC. Obwohl es von DWM unterstützt wird, wird dies aufgrund der verringerten Leistung nicht empfohlen.

Vermeiden Sie das Zeichnen im Nichtclientbereich. Obwohl die Anwendung auf diesen Bereich zugreifen kann, und das Zeichnen dort von der Microsoft Win32-API unterstützt wird, kann dies dazu führen, dass das Fenster jeden Glasrahmen verliert, den es hat.

Vermeiden Sie die Vermischung von Windows Graphics Device Interface (GDI) und Microsoft DirectX, es sei denn, sie überschneiden sich nicht. Wenn das Mischen erforderlich ist, zeichnen Sie entweder den GDI-Inhalt in eine DirectX-Softwareoberfläche, und kombinieren Sie sie, bevor Sie auf dem Bildschirm komponieren, oder zeichnen Sie sie in separaten Fenstern.

Verwenden Sie die Funktion BitBlt oder StretchBlt anstelle von Windows GDI+, um Ihre Zeichnung zum Rendern darzustellen. GDI+ rendert jeweils eine Scanzeile mit Softwarerendering. Dies kann zu Flimmern in Ihren Anwendungen führen.

DWM-Blur-Behind-Clientregion

Das Rendern des Weichzeichner-Behind-Effekts ist ein ressourcenintensiver Vorgang sowohl für die CPU als auch für die Grafikverarbeitungseinheit (GRAPHICS Processing Unit, GPU). Anwendungsentwickler werden dringend aufgefordert, die Auswirkungen der Verwendung von Unschärfe im Clientbereich zu berücksichtigen, damit sie keine übermäßigen Ressourcen verbraucht. In den folgenden Fällen sollten Sie besonders vorsichtig sein:

  • Wenn Sie erwarten, dass die Größe der Unschärfe des Clientbereichs erheblich ist, auch wenn keine Updates im verschwommenen Bereich selbst erfolgen. Die Unschärfe muss gerendert werden, falls Updates im verschwommenen Bereich des Fensters auftreten, was CPU- und GPU-Kosten verursacht. Darüber hinaus verursachen Fenstervorgänge im Fenster (Verschieben/Ändern der Größe/Übergänge) mehr Kosten.
  • Wenn Sie erhebliche Updates im verschwommenen Clientbereich erwarten. Dies erfordert eine Neubemalung der Unschärfe bei jedem Update und einen übermäßigen Ressourcenverbrauch.
  • Wenn erwartet wird, dass die Unschärfe einen erheblichen Bereich abdeckt und auch Updates für diesen Bereich erwartet werden, wird dringend empfohlen, den Clientbereich nicht zu weichzeichnen.