Settings UI bugging out

[Minnona]

Sometimes Settings UI just freezes upon opening.

[ShankarBUS]

I'll look into it, thanks for reporting.

[Samuel12321]

Also experienced this problem

[prakharb5]

Same here. Though flyouts still work fine.

[prakharb5]

I also noticed that when this bug happens, there is a bit high CPU usage. But the settings window remains blank.

[prakharb5]

Observed that after prompting flyout once or twice, it fixes this issue.

[ShankarBUS]

This bug is getting too tricky. I guess I have to fix this ASAP.

[prakharb5]

I am suddenly not able to open settings.

[ShankarBUS]

From tray? jumplist? flyout window settings button? Be more specific

[ShankarBUS]

Guess what? Now I got the same bug 🤦‍♂️. Need to do this as the first fix for v0.6

[prakharb5]

So you have met this. Nice.

[prakharb5]

If it helps, maybe. System usage stays like this until the window is closed.

[ShankarBUS]

This could be a issue with ModernWpf (i.e. the UI library this app relies on).

Unlike the flyout, the settings window doesn't stay alive after we close it. It will be created again on need. Thus by theory it should be refreshed and work fine when we close & reopen it again. But that doesn't happen meaning the UI library is causing some trouble.

When the settings window lags, the tray icon also lags (doesn't show contextmenu or tooltip but the flyout works perfectly fine). This could be solved iff we move to WinUI.

So, this could either be caused due to ModernWpf or WindowChrome feature of WPF.

[prakharb5]

And, if we don't kill the window, it would consume memory and CPU in background, right?

[ShankarBUS]

It should automatically be killed by dotnet's garbage collector (if we untie all references to it). But that should affect a new window.

I'm confused why a new window lags that much

[prakharb5]

Maybe because it has to load everything from start, I guess?

What if we don't kill the settings page? When we launch the app, it would start the settings page process too. When prompted, the window will pop up. Otherwise. it can be hidden.

[ShankarBUS]

But it'll hold some additional memory, which will degrade performance of the system.

We already have the flyout window persistent over a session. It already degrades the performance.

In the future we may add multiple groups and pages to the settings as the app evolves, so keeping it persistent will be a major performance issue.

Loading all the contents again is not the problem (won't make any difference) but the window content is not rendered properly. You can still close the window, maximize it or minimize it, meaning that it is not frozen but not rendered properly.

You won't see any visual updates when you hover or maximize the window. So it seems to be a problem not with our implementation but a bug in WPF's WindowChrome feature

[Samuel12321]

45

[ShankarBUS]

Hey @Samuel12321, this issue seems to take a lot of testing before fixing because there are no solid ways to reproduce this issue perfectly. It happens sometimes and it doesn't sometimes. Can this be moved to v0.8 project?

We can focus on the settings window completely during that period

[Samuel12321]

Sounds like a good idea to me.

[Samuel12321]

so is 0.6 done now

[ShankarBUS]

Yes... I can't fix the settings window frozen bug for now. Can you release v0.6 now with the current set of fixes?

We can do a minor release later, switching to .NET 5.

[Samuel12321]

settings window frozen bug moved to 0.8

will package 0.6 now

[ShankarBUS]

@Samuel12321, I don't know what's causing this but you gotta see this

[Samuel12321]

WHAT THE HECK IS GOING ON WITH THE SETTINGS MENU.

What version is this (0.6 release ?)

[ShankarBUS]

Yes, I'm really confused about what's causing this

I know sure that previously the Window was responsive but the content didn't render properly (tile bar buttons didn't update on hover or click but they worked). So, I removed the custom window border. Now the window frame is completely responsive meaning that the window is not "frozen" but there are some rendering issue.

When I lower the window size, it renders fine and there are no issues. It could probably be a issue with the NavigationView.

I need to tweak the window's content and find a way to tackle this

[prakharb5]

One more blank, with resources usage. The window is completely blank. Did you tweak something?

[ShankarBUS]

Oh I was tweaking properties of the settings window locally didn't want to push it to GitHub 😅.

You experience that issue because the whole window content including the titlebar, caption, control boxes and window border are all rendered by WPF (ModernWpf takes care of the styles & themes).

The one you see above (the one I posted) is different, only the content is rendered by WPF the window chrome (title bar, control box, caption & border) is rendered by Windows itself. So the cases are different. I suspect the NavigationView from ModernWpf to be the culprit

It interrupts the rendering process somehow. It make it so the window only render on a small size

[ShankarBUS]

Got another one - https://www.codeproject.com/questions/186913/wpf-application-windows-does-not-fully-refreshed-a

This bug also happens after waking up from sleep.

[Samuel12321]

still a problem with 0.7.5

[ShankarBUS]

I never said I fixed it.

[prakharb5]

Noticed a thing. When the settings page is blank, summoning the flyout renders the page completely. Can't guarantee if it always works, but do try. I was able to fix it 2 out of 2 times. So yeah, this works for me.

[ShankarBUS]

Yup, I was experiencing the exact same things.

I will press CapsLock to show the flyout when the settings window lags.

This is too confusing now 😑

[prakharb5]

For now, can we do it like, we open the settings, and the flyout is triggered once? Can be a temporary fix for now, I guess.

[ShankarBUS]

@Cyberdroid1,

For now, can we do it like, we open the settings, and the flyout is triggered once? Can be a temporary fix for now, I guess.

We can show the flyout with 0 opacity while opening settings to fix the issue for now.

But the real problem is this problem also occurs after waking from sleep or from lock screen (Win + L). It will also make the tray icon non responsive.

One way would be to show the window all time (i.e. 0 opacity instead of hiding it). This way we can eliminate this issue. But it may have some side effects.

That's why I'm still searching for other methods to tackle this. Let's be patient for now 😔

[ShankarBUS]

Got some info on this.

Seems like the flyout window gets into a "WM_PAINT storm" stuck in a render loop causing the app to be un-responsive and rooting this bug. Opening the flyout window relieves the loop somehow. So, the only workaround is to show the flyout window all the time. When not needed we can set its opacity to 0. I'm not sure if this could be fixed or not. But let's try at least.

https://github.com/dotnet/wpf/blob/c3b1ecefd9debf850b4757bb8d657b15af79469d/src/Microsoft.DotNet.Wpf/src/WpfGfx/core/uce/hwndtarget.cpp#L361

https://github.com/dotnet/wpf/blob/c3b1ecefd9debf850b4757bb8d657b15af79469d/src/Microsoft.DotNet.Wpf/src/WpfGfx/core/uce/hwndtarget.cpp#L730

https://github.com/dotnet/wpf/blob/c3b1ecefd9debf850b4757bb8d657b15af79469d/src/Microsoft.DotNet.Wpf/src/WpfGfx/core/uce/hwndtarget.cpp#L1183

https://github.com/dotnet/wpf/blob/0d45071da6184257340632aaeb15a04a7b035ab6/src/Microsoft.DotNet.Wpf/src/PresentationCore/System/Windows/InterOp/HwndTarget.cs#L159

https://github.com/dotnet/wpf/blob/0d45071da6184257340632aaeb15a04a7b035ab6/src/Microsoft.DotNet.Wpf/src/PresentationCore/System/Windows/InterOp/HwndTarget.cs#L1212

[ShankarBUS]

Keeping the flyout always on screen fixes this bug. The opacity will be set as 0 instead of hiding the flyout. Mouse inputs won't be blocked by it, don't worry. But the window is still visible to screen snipping tool. I'll dig into this and find a better workaround.

[ShankarBUS]

Whew!!!! 😌 Finally fixed this bug after ~2.5 months.

I will commit the changes tomorrow.

Thank y'all for your feedback and support guys!

Forgive me for taking this long to fix this bug. I should have spent more time on high priority issues like this instead of some low priority UI features 😅.

The fix was indeed so much simple 😃.

I'm very sorry again 😅.

[Minnona]

Glad to hear that, good job!

[ShankarBUS]

Done guys! 2dd91390bc2d06382ae4fad3c12adb967a6d2b56 Finally got the time to commit the bug fix. Whew 😌

Now, please be patient until you receive v0.8 update via MS Store or from this repo. Beta flight users will get the update before normal users.

[prakharb5]

I have found another problem. Sometimes the settings window is just frozen. It does not respond. Though the content renders, it is unresponsive. I have to trigger the flyout once to get it working. Please fix this.

[ShankarBUS]

I have found another problem. Sometimes the settings window is just frozen. It does not respond. Though the content renders, it is unresponsive. I have to trigger the flyout once to get it working. Please fix this.

Just reactivate the window by clicking out of the window and then activate it through task bar or task view or by clicking on the window again. Or just close and re-open the window.

This is it. Not more workarounds for this. These are the only things I know.

[prakharb5]

Oh, alright. 👍