GPU usage of DWM

[ltetak]

I notice weird behavior on Windows. GPU usage is high (~30% on my machine - split 1:1 between app and DWM) even if nothing is rendered. It seems even rendering nothing causes big GPU usage. I found three places where things may get improvemed

1. Animations are running even if the control is not visible (but present in the Visual tree). e.g. IsVisible=false progressbar causes 60FPS rendering which causes GPU consumption (even if the app is idle otherwise)
2. Composition - BeginDraw method redraws the whole surface all the time. It could use dirty rect at this point.
   

   Avalonia/src/Windows/Avalonia.Win32/WinRT/Composition/WinUiCompositedWindowSurface.cs

   Line 146 in da523ff

   off = _surfaceInterop.BeginDraw(null, &iid, &pTexture);

3. Surface always creates Alpha texture which may not be necessary if not used by the app
   

   Avalonia/src/Windows/Avalonia.Win32/WinRT/Composition/WinUiCompositedWindowSurface.cs

   Line 86 in da523ff

   _drawingSurface = _compositionDevice2.CreateDrawingSurface2(new UnmanagedMethods.SIZE(),

Does anybody have any advice?

[maxkatz6]

Can you try Win32RenderingMode.DirectComposition? It will likely have the same issues, but could show different numbers still.

[ltetak]

Thanks for the tip @maxkatz6.
DirectComposition does not make a significant difference.
LowLatencyDxgiSwapChain makes app GPU usage a bit higher but the DWM drops almost to zero. So that would look like a quite good solution if stable.
btw. my test setup is simply switching the sample ControlCatalog app to the Progress bar page.

I am still wondering about the BeginDraw part. Why does it make a difference if I constrain the area here (the first RECT argument)? I saw some examples (UWP one) where they also pass null (no constraint). Is it possible there is some other part down the pipeline where this constrain is missing and we are updating more than necessary? I saw a couple of .Clear() commands that might touch more pixels than necessary.

[maxkatz6]

I don't think DMW is much involved with LowLatencyDxgiSwapChain, it should be bypassed at best.

I am still wondering about the BeginDraw part

I am not sure about this part. It doesn't really look like we pass dirty rects there either.

We previously had ITopLevelImpl.Invalidate method which was used to tell the OS about dirty rects - https://github.com/AvaloniaUI/Avalonia/blob/0.10.22/src/Avalonia.Controls/Platform/ITopLevelImpl.cs#L113-L116.
And as far as I remember, a composition renderer always uses a single dirty rect right now on each redraw. @kekekeks might know this part better.

[maxkatz6]

The animation problem is another issue, not related to the dirty rects. But likely to be a bigger reason for performance issues here.

[ltetak]

Animation just kicks in the rendering (invalidates) 60 times per second and animation of an invisible object makes it obvious that even a scene with no dirty rects uses a lot of GPU. If one would have a scene where the whole area changes it would have the same performance as it has now. But if you animate a single text value the difference would be significant.

I added this PR #13912 where I simply clip the target surface. It seems to help to lower the application GPU usage. It does not help the DWM though. I am not sure how this plays with the double buffering. If we could draw directly to the target context then it would be even faster.