How to remove the flickering of WinUI3 Window on resizing

[selastingeorge]

I am new to WinUI3, I have created a sample app and when I resize it, there is a flickering in window, In WPF it was able to fix this flickering issue. but on winUI3 it is not working, is there any way to fix it.

I know that The Content Rendered in the window is created by Direct Composition and all the contents are hosted as a child window in a parent window, and i usually adjust WndProc to adjust the flickering some how I was not even able to override the wndPoc like i did for wpf, is there any way to fix this flickering.

Here is the screenshot of the issue:

[codendone]

We're currently working on fixing this. The plan is that instead of having that background color always be white it will instead be white or black depending on the value of Window.Content.RequestedTheme.

[selastingeorge]

The How can i get access to the WndProc, will sub classing work ?
Why is it not possible to create a transparent window, i just added used the SetWindowCompositionAttribute() and set it to INVALID_STATE, usually it creates the same effect as the WS_EX_NOREDIRECTIONBITMAP in WPF but in Win UI some white background is covering the window,.

[float34]

@codendone So instead of properly synchronizing the rendering with window sizing events you simply want to hide the issue by coloring? How will it help to eliminate the obvious title bar buttons flicker?

[niels9001]

Agree with @Torquerrr - and what if there's a custom image / gradient background set? This doesn't sound like an actual solution to the problem..

[selastingeorge]

When i checked the window with Spy++ i found that the child window hosted inside the parent is uses class Microsoft.UI.Hosting.Experimental.ContentWindowBridge, when i checked the caption of window this shows DesktopWindowBridge, which points me to other classes their in which one (Microsoft.UI.Hosting.Experimental.ExpSystemVisualBridge) has background property, will it be helpful, these are undocumented and i don't know what it does ?

And Check out these :

Here the Child window uses WS_EX_NOREDIRECTIONBITMAP Which means the Child window draws a background using Direct Composition and the Window actually doesn't have a background.

[llothar]

We're currently working on fixing this. The plan is that instead of having that background color always be white it will instead be white or black depending on the value of Window.Content.RequestedTheme.

Thats a hack but it's not a solution, why is it rendered when not ready? The window resize is already delayed from the mouse dragging, so why not just syncing it. Windows is the only OS where this still happens. A simple color theme will not help if a sidebar is jumping around like a cat in heat.

[selastingeorge]

We're currently working on fixing this. The plan is that instead of having that background color always be white it will instead be white or black depending on the value of Window.Content.RequestedTheme.

Thats a hack but it's not a solution, why is it rendered when not ready? The window resize is already delayed from the mouse dragging, so why not just syncing it. Windows is the only OS where this still happens. A simple color theme will not happen when the sidebar at that location is jumping around like a cat in heat.

I have used Windows.UI.Composition wpf samples, those windows were also having the flickering but i was able to fix it by setting the window style to none and allow transparency to true. i think it won't work here.

Here is a sample wpf app:

[float34]

@selastingeorge Seems to be the same issue as #2506.
It is a long standing problem with how Windows handles the window resize. You can read how bad it actually is here.
I don't expect it to be fixed ever.

[selastingeorge]

Actually i fixed the flickering issue in WPF by overriding the WndProc. Responding to WM_NCCALCSIZE with any RECT smaller than the window solves the problem. But i don't know it will work on child windows

[codendone]

Lots of good discussion on this thread. I agree with comments that setting a better background color is an incomplete solution, but as @Torquerrr said, handling resize well in Windows is difficult. Windows has code to attempt to synchronize window frame redraw with when the app content has finished drawing, but that synchronization code requires Windows to know when the app is finished drawing. WinUI3 draws all app content into a swapchain, which Windows intentionally never synchronizes to favor performance of the swapchain. Window resize is a case where synchronization might be desirable. I think this needs to be investigated, but supporting synchronized resize would be significant work and likely requires an OS update.

Because of all that, a better background color will at least reduce the visible flicker for dark theme apps without waiting for a full synchronized resize solution.

[selastingeorge]

I Know this is not the question i should ask in this thread, but it's just a small doubt ,I was also trying to implement transparent background and acrylic effect also in win ui3, i was able to implement both in Win32 using the DWMThumbnail API, but the DWM Thumbnail Api Outputs the Content Behind Window on to IDCompositionVisual2 , is there any way to convert it to Microsoft.UI.Composition.Visual

Here is the demo screen shot:

Here the Position i marked using Red Rectangle is not caused by WS_EX_NOREDIRECTIONBITMAP, its dwm thumbnail based,
After blurring it will be:

If I could get these visual to Microsoft.UI.Composition.Visual, I might be able to bring back Transparency+ Acrylic to win UI 3, I believe So.

[float34]

@codendone As far as I know default Windows 10 apps (News, Maps, Photos) use DirectComposition API, and they don't have the resize issue being discussed.
Why WinUI 3 draws to swapchain (with DXGI_SWAP_EFFECT_FLIP_SEQUENTIAL/DXGI_SWAP_EFFECT_FLIP_DISCARD I guess?) instead? To cover the needs of both 2D apps and 3D games (which need maximum performance)?

[codendone]

@Torquerrr WinUI 3 uses Microsoft.UI.Composition, which is part of Project Reunion, rather than Windows.UI.Composition. Using Microsoft.UI.Composition means we can update it when desired, just like we can with the XAML code of WinUI 3, and that those updates are available on all OS versions supported by Project Reunion, rather than only being on the latest OS version.

[float34]

@codendone So, do we need to add "feature-request" label or close it and all relevant stories?

[codendone]

We should keep this active, and I think just an issue is fine here. This is being tracked internally as a feature due to its cost and complexity.

[etkramer]

Definitely with everyone else in this thread, syncing the clear color with the Windows theme is not a solution. The proposed hack would look just as bad as it does now if the page:

a. Uses a background color that doesn't perfectly match the windows theme
or b. has content anywhere near the edges

[chausner]

The plan is that instead of having that background color always be white it will instead be white or black depending on the value of Window.Content.RequestedTheme.

I agree with the others that this seems a poor workaround at best. Still, a workaround that makes these artifacts less noticeable is better than no fix at all, at least until a proper fix is available. It would be good, however, to be able to set a custom color for this instead of having white/black hardcoded. My app, for example, uses an orange background, so neither white nor black looks good.

[nathanAjacobs]

Is there an update on this? This is turning me away from wanting to use WinUI 3.

[castorix]

Is there an update on this? This is turning me away from wanting to use WinUI 3.

There is no more flickering :

[wangwenx190]

We should keep this active, and I think just an issue is fine here. This is being tracked internally as a feature due to its cost and complexity.

@codendone May I ask the current status of this internal ticket? Is it ever been worked on since it's created?

[wangwenx190]

Is there an update on this? This is turning me away from wanting to use WinUI 3.

There is no more flickering :

@castorix That looks a lot better, but can you verify whether the content still flickers or not if you remove the whole window frame (by not modifying the non-client area and returning 0 directly in WM_NCCALCSIZE) ? And from your video it looks like the contents are jumping around because of window resizing, that's really not nice.

[castorix]

@castorix That looks a lot better, but can you verify whether the content still flickers or not if you remove the whole window frame (by not modifying the non-client area and returning 0 directly in WM_NCCALCSIZE) ? And from your video it looks like the contents are jumping around because of window resizing, that's really not nice.

If I remove the frame by subclassing it, the result is the same (I can only resize once as there is no more sizing border...)
But the jumping content is clearly not good (if I test resising with WPF for example with also a centered button, it is smoother)

[nathanAjacobs]

Did you test the resizing from left side, which still flickers with custom colors in my tests ? I made other tests and I could remove this flickering by handling WM_NCCALCSIZE instead of WM_SIZE... but I replaced the default Swapchain with my own Swapchain (with CreateSwapChainForComposition) for the test (so XAML is not drawn anymore, just what I draw in my Swapchain...), by using the method in this article DXGI Flip Model Flickering During Live Resize

So I ended up retesting, and there is a chance of a flicker still, but it is rare and I have to move my mouse really fast when resizing the window:

flicker.mp4

The jittery movement of the content when resizing from the left side, in addition to the content popping in and out occasionally is definitely more jarring.

jitter.mp4

[MattBDev]

I can't believe that this issue still exists. I consider it a major regression from UWP apps which handle resizing without a problem.
This issue should be marked as a bug instead of a question since this shouldn't be the intended behavior. Apps should resize smoothly without any flickering.

[Lightczx]

Workarounds not doing well when using the 1.1 MicaBackdrop/SystemBackdrop feature.
Since it is not solid, filling color when resizing really helps nothing.

[github-actions]

This issue is stale because it has been open 180 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[xStrom]

The issue isn't stale.

[llothar]

The issue isn't stale.

Windows is stale at the moment, at least it taste like this.

[JJBrychell]

The "partial" fix has been completed and a more comprehensive fix has been added to the backlog so changing this to a feature proposal.

[AndyHTML2012]

@JJBrychell any update on when this might be fixed in WinUI3?

[wuyang26]

WPF will also encounter the same problem in custom windows，However, setting NonClientFrameEdges="Bottom" in Windows Chrome eliminates flickering issues：
<Setter Property="WindowChrome.WindowChrome"> <Setter.Value> <WindowChrome CornerRadius="0" UseAeroCaptionButtons="False" NonClientFrameEdges="Bottom" ResizeBorderThickness="6" GlassFrameThickness="1"/> </Setter.Value> </Setter>

[Sebbe909]

@farran 100%. Windows is the cripple handicapped kid from the block. It's terrible. MS, but in particular Windows, is a complete joke compared to any other OS nowadays. How did Satya Nadella ever think this (and related stuff, like W11 in general) was ready to ship considering the horrible UX/UI experience? No wonder Panos Panay left the building.

Remember the time where Vista was able to render Aero blur effect real time without any lag or crazy stuff whatsoever. This was almost 20(!!) years ago. Now, on high end hardware, you can literally see the Acrylic effect being drawn over the window background when resizing, has Explorer.exe trouble to load up the UI instantly, renewed Task Manager which feels like a slow responsive pile of garbage, etc. etc...

It's a total utter mess.

Not surprising as senior and experienced devs move up the ladder (and bail) and most of the dev is supposedly done by junior (medior at most) devs in India. And I hear India is known for high quality software development.

But yeah, MS is only a startup right.

Yes I'm frustrated, because all MS does is near to nothing to improve the overall performance. From time to time they seem to check out the feedback hub to see which unneeded bloated feature they should add in the next "major update". Awesome idea to let the gamer kids tell MS what should be important.

Just my 2ct.

[Neme12]

This issue doesn't happen for built-in apps on Windows 11 like File Explorer or Notepad, even though they seem like they're in WinUI by the style. Also, they open much quicker than a WinUI app. Maybe they're actually written in something completely different? That would support #9417

EDIT: Oh, actually they do, I can see that when resizing via the top or left sides rather than the bottom or right sides, where I don't notice it.

(see this video from 2013).

Wow, this looks out of this world to me, since I'm used to Windows. This certainly doesn't happen for any app on Windows. I think I'll switch OS 😄

[Lightczx]

This issue doesn't happen for built-in apps on Windows 11 like File Explorer or Notepad

File Explorer do have flickers, since it's HWND + Xaml island

[AndyHTML2012]

This issue has been open since 2021 and is still one of the most noticeable visual bugs in WinUI3.

[JamasChuang94]

有更新吗？这让我不再想使用 WinUI 3。

不再有闪烁：

This only solves the problem of solid colors, but the system acrylic and Mica backgrounds will still flicker. How do I resolve rendering issues with SDK1.5?

[mominshaikhdevs]

@codendone has this issue been fixed at the OS level yet? what's the latest update on this?

[codendone]

@mominshaikhdevs There has been a little progress, but no ETA currently. See http://aka.ms/winappsdk/plans for the overall roadmap.

[holecekp]

The same issue is also in .NET MAUI (based on WinUI3). Old Xamarin.Forms (UWP) did not have this issue and resizing is smoother there.