Fix issues with High CPU Usage on background #3278
Merged
+272
−49
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
… once the app window is shown again
…hen launched as daemon
…obally - this issue was spotted thanks to telemetry :)
…ve write permissions on the settings directory
…admin", "debug build", etc
4 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There is an issue that has happened since UniGetUI (then WingetUI) was migrated to WinUI3/AppSdk: There is a permanent ~1%ish CPU usage that won't go away. This is no big deal desktop PCs unless you have an old machine, but laptops suffer from battery drain and overheating when closed due to this issue (I experience this on my own laptop). Looking at Process Explorer, I realized this CPU was used by some WinUI dwmapi.dll thread, and not by any UniGetUI component.
There are lots of open issues on microsoft/ui-xaml, such as this one: microsoft/microsoft-ui-xaml#9703
After some testing, I found out that suspending the thread automatically freezes the window, but my code is actually still running, the frozen part is only the renderer. Therefore, why not suspend the renderer when UniGetUI is running on the background, and unfreeze it when the window shows again?
This is what this PR does: Freeze the render thread on window hide, and unfreeze it on window show.
I don't know how stable this code will be. It is a proof of concept that will (probably) be tested by prerelease users, and perhaps introduced partially into stable at some point.
The suspended threads are:
dwmcoreapi.dll+0x54F70Microsoft.UI.Xaml.dll!XamlCheckProcessRequirements+0x539b0(represented byMicrosoft.UI.Xaml.dll+0x5B1F0)This feature can be disabled from the Settings Window, under Experimental Features.
fix #2049