Settings UI bugging out about modernflyouts HOT 42 CLOSED

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 😅.

from modernflyouts.

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

from modernflyouts.

so is 0.6 done now

from modernflyouts.

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

from modernflyouts.

I never said I fixed it.

from modernflyouts.

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

from modernflyouts.

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.

from modernflyouts.

Glad to hear that, good job!

from modernflyouts.

Also experienced this problem

from modernflyouts.

Same here. Though flyouts still work fine.

from modernflyouts.

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

from modernflyouts.

So you have met this. Nice.

from modernflyouts.

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

from modernflyouts.

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.

from modernflyouts.

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

from modernflyouts.

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.

from modernflyouts.

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

from modernflyouts.

Sounds like a good idea to me.

from modernflyouts.

settings window frozen bug moved to 0.8

will package 0.6 now

from modernflyouts.

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

from modernflyouts.

WHAT THE HECK IS GOING ON WITH THE SETTINGS MENU.

What version is this (0.6 release ?)

from modernflyouts.

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

from modernflyouts.

still a problem with 0.7.5

from modernflyouts.

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 😑

from modernflyouts.

@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 😔

from modernflyouts.

Oh, alright. 👍

from modernflyouts.

I'll look into it, thanks for reporting.

from modernflyouts.

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

from modernflyouts.

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

from modernflyouts.

I am suddenly not able to open settings.

from modernflyouts.

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

from modernflyouts.

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

from modernflyouts.

#45

from modernflyouts.

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

from modernflyouts.

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.

from modernflyouts.

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

from modernflyouts.

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.

from modernflyouts.

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.

from modernflyouts.

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.

from modernflyouts.

Done guys! 2dd9139
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.

from modernflyouts.

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.

from modernflyouts.

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.

from modernflyouts.