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)

[castorix]

2022-06-11.09-23-47_Trim_Trim_Trim.mp4

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

[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

There is no flickering with custom colors when resizing from the left side for me. Although the content repositioning is more jittery when resizing from the left size for some reason.

Here is the link to the repo: https://github.com/nathanAjacobs/WindowBackgroundDemoWinUI3

I would really like to see a Background property added to the Window class in the framework itself, that way all this extra workaround isn't required. It would also be nice if it was able to be bound to a ThemeResource brush.

[castorix]

Yes, the idea is to erase the background with the same color as the current background, to hide the flickering
I think that's why they added a black/white background, depending on the Theme

If a border is added, the flickering is visible (but usually, nobody adds a border to a main window...) :

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

[farran]

Firstly, please excuse my ignorance, I am a technically-minded user but I have no experience in the professional world of programming. I'm studying it now but I'm no programmer just yet.
My following comments and ideas are from my naïve perspective and experience.

I am on Windows 10, latest updates, stable channel. (22H2, 19045.3271).
I have Intel Core i7 11th gen with an iGPU and a discrete Nvidia GPU. The Nvidia GPU is not used for desktop rendering and is disabled until I need it for a task. I have 16 GB RAM.

Usually the newer UI apps (I mean UWP and WinUI 3) like WhatsApp, Calculator, Calendar, Microsoft Store, To Do, PowerToys etc resize synchronized.
WhatsApp actually has the smoothest-appearance resize-redraw effect, except for when it is moving through its responsive layout element repositioning.

Some other modern apps like Windows Settings (which is UWP too, isn't it?) always resize terribly; they have some kind of sync going on sometimes, but the UI often fails to redraw in large chunks around the distal edges (i.e. right, bottom).
Some apps usually redraw well, such as File Explorer and some modern Qt apps.
Most regular desktop apps have this flickering effect though.
When the CPU is under load, most - maybe all - apps resize badly.

I mention this because, up until today, I was under the impression that WhatsApp (& co) are redrawing in real sync with the resize function.
However, this morning I resumed my laptop from hibernation and found that all the resizing is bad - even the lightest-weight apps like Calculator cannot sync or redraw correctly.

I have reset the graphics driver with Ctrl+Shift+Win+B, restarted Explorer.exe, restarted dwm.exe.
From other behaviours of my laptop right now, it seems as if some drivers have been unloaded. Rebooting would probably fix it.

Here's a video of the resizing performance right now, recorded without restarting the login session or rebooting the OS.

07.08.2023_11.20.12_REC.mp4

This makes me wonder, how does the apparent synchronization in those apps work? Is it faked? If the synchronization were part of the fundamental function of the window manager, would it not continue to work regardless of the driver or window manager software state?
Are the apparent improvements (e.g. in WhatsApp) also hacks?

Even old versions of OSX and X11 could synchronize resize and redraw. Despite its shortcomings, sync in Wayland is next level, even with nested X11 servers for non-Wayland apps. Compiz was way beyond its time (and seems to still be present in KDE's Plasma), and early Mutter had incredible sync (without proprietary graphics drivers) - even with Chrome window resizing (see this video from 2013).
I appreciate that Windows is a different beast.

Even when I used Windows 11 for a few months last year, resizing windows (and even moving them around) had a somewhat custardy feel to it.

I would imagine that, if the window manager software has synchronizability built into it, then any other toolkit could connect to that function/protocol.

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.

Turning on synchronization presumably impacts performance too much, because Windows intentionally prioritizes performance over synchronization, as codendone mentions above. So, I think an additional question to investigate is, why does synchronization impact the performance so much, and can that be improved?

And, imo, synchronization for resizing windows should probably be on by default, with a flag to disable it for apps which demand the highest available performance (games, CAD, etc). Resizing a window doesn't happen that often, but the desync is a very jarring experience.
If that isn't in line with Microsoft's intention with Windows, then perhaps it would be good to have it as something that can be activated by the user, such as the Visual Effects in Adjust the appearance and performance of Windows and the glassy blur effect.

Apple capture people's hearts because the UI appearance & interaction is smooth and calm; even if something is slower to draw, perhaps mildly laggy, the animation is smooth and elements do not jump all over the screen.
Windows does look & feel broken, quite a lot of the time.
And with the lack-of-redraw that you can see in my video, it can take multiple attempts to be able to see the entire window's contents, which is necessary if you wanna do things like see and click on things. That UX is actually broken.

Thanks for your efforts towards this bug, I appreciate the probable complexity of how many layers of software must be involved for this kind of synchronization to work. I hope it can be resolved soon, to bring a desktop experience that feels and appears more stable, calm and consistent.

[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?