Dela via


Prestandaöverväganden och metodtips

I det här avsnittet beskrivs en uppsättning metodtips för att använda API:erna för Desktop Window Manager (DWM).

Det här avsnittet innehåller följande avsnitt:

Tillämpningsmetoder för DWM

Om ditt program hanterar skalning av punkter per tum (dpi) kan du deklarera ett program som dpi-medvetet och förhindra automatisk skalning genom att ange flaggan dpi-medveten i programmets manifest eller genom att anropa SetProcessDPIAware funktion under programinitiering.

När DWM-kompositionen är aktiverad får dolda program inte längre WM_PAINT meddelanden och uppmanas inte att åter rendera. Varje fönsters innehåll är redan tillgängligt för att skapa skärmbilden.

Överordnade WS_EX_TRANSPARENT-fönster bör kombineras med en WS_EX_LAYERED-stil för träfftestning. WS_EX_TRANSPARENT i klassisk mening, utan omdirigering, är användbart för underfönster i en hierarki med fönster som tillhör samma tråd, men det är inte avsett för huvudfönster.

Använd regioner eller lager för att skapa formade eller blandade fönster. Observera att i Windows Vista och senare versioner av Windows kommer anpassad ritning av endast en del av ett top-level-fönster inte att ge det önskade föråldrade innehållet i odragnade regioner.

API:er som GetDCOrgEx kan användas för att fastställa vissa faktiska värden. Om du har en enhetskontext (DC) för ett omdirigerat fönster matchar inte ursprunget som returneras av GetDCOrgEx fönstrets ursprung på skärmen. Ursprunget kommer istället att vara ditt fönsters backbuffertytas ursprung: (0, 0).

När allt annat misslyckas inaktiverar du fönsterrendering genom att anropa funktionen DwmSetWindowAttribute.

Ritningsmetoder för DWM

Undvik att rita direkt till den primära visningsytan. Detta tvingar DWM att inaktivera kompositionen tills din applikation släpper den primära enhetsytan.

Utvärdera om ditt program måste tillhandahålla en egen dubbel buffring. DWM använder effektivt dubbelbuffring för innehåll och presenterar fönstret i en enda bildruta.

Undvik att läsa från eller skriva till en visnings-DC. Även om det stöds av DWM rekommenderar vi det inte på grund av lägre prestanda.

Undvik att rita i området utanför klientområdet. Även om det här området kan nås av programmet, och ritning där stöds av Microsoft Win32 API, kan det leda till att fönstret förlorar alla glaskantlinjer som det har.

Undvik att blanda Windows Graphics Device Interface (GDI) och Microsoft DirectX om de inte överlappar varandra. Om blandning är nödvändigt kan du antingen dra GDI-innehållet till en DirectX-programvaruyta och kombinera dem innan du skriver till skärmen, eller rita dem i separata fönster.

Använd funktionen BitBlt eller StretchBlt i stället för Windows GDI+ för att presentera ritningen för rendering. GDI+ återger en skanningslinje i taget med programvarurendering. Detta kan orsaka flimmer i dina program.

DWM Blur-Behind klientregion

Att återge blur-behind-effekten är en resursintensiv åtgärd för både processorn och grafikprocessorn (GPU). Programutvecklare uppmanas att överväga konsekvenserna av att använda oskärpa i klientområdet så att det inte förbrukar alltför stora resurser. Du bör vara särskilt försiktig i följande fall:

  • När du förväntar dig att storleken på klientområdets oskärpa ska vara betydande, även om inga uppdateringar sker i själva det suddiga området. Oskärpan måste återges om några uppdateringar inträffar under fönstrets suddiga område, vilket medför cpu- och GPU-kostnader. Dessutom medför åtgärder på fönster (flytta/ändra storlek/övergångar) högre kostnader.
  • När du förväntar dig betydande uppdateringar i det suddiga gränssnittet. Detta kräver en ommålning av oskärpan för varje uppdatering och förbrukar överdrivna resurser.
  • Om oskärpan förväntas täcka ett betydande område och uppdateringar av det området också förväntas, rekommenderar vi att du starkt undviker att göra klientområdet suddigt.