Windows 10 1903 Window Drag Issue

[HEIC-to-JPEG-Dev]

Hi, I just upgraded to Windows 10 1903 and noticed that using the titlebar to drag a window has a very high latency, lagging behind the cursor movements by seconds.

I'm using the AcrylicWindow with ExtendViewIntoTitleBar="True"

Thanks for any updates.

[Andrei-Lapusteanu]

Experiencing the same issue on my 1903 build, could not yet figure out a solution.

[vivaladan]

I've only just discovered FluentWPF but have hit this issue right away on 1903 with a super simple new app.

[sourcechord]

Hi, @DHitchenUK
Sorry for replying so late.
Thanks for the information.
I recognized your reporting issue.
I'm inspecting the behavior of FluentWPF in Windows10 19H1, and trying to fix it.
Please wait for a while.

[HEIC-to-JPEG-Dev]

@sourcechord, I just wanted to say thanks for the work you put in, it's very much appreciated.

[dsafa]

If you turn off transparency effects in the settings, it works like before. Of course this turns off blur for all windows apps however.

[sourcechord]

Hi, @DHitchenUK
Maybe, it is same as riverar/sample-win32-acrylicblur#2

FluentWPF uses undocumented Win32API(SetWindowCompositionAttribute method).

The reported behavior is caused by the change in the behavior of that API.
It seems that SetWindowCompositionAttribute API is broken in Windows10 1903.

Dragging problem occurs Windows10's emoji toolbar, too.
(that is shown by Win+period key)
And, these problem is reported in Feedback Hub.
https://aka.ms/AA4pzyf
https://aka.ms/AA4fmz7

Please upvote it 🙏

[ashelleyPurdue]

I'm still getting this issue even after updating to FluentWPF 0.7.0.

EDIT: Actually, this is strange. The issue doesn't occur on my work computer, but does still occur on my home computer. I'll try it again on my home computer to see if I did something wrong.

[ghost1372]

This bug seems to be fixed in version 1903 (18362.267)

[0xCA]

This bug seems to be fixed in version 1903 (18362.267)

18362.295, still here

[JVimes]

Is this supposed to be open? 637ea17 did not fix it for me (Windows 1903, OS build 18995.1)

[Armin2208]

In 1909, or a new cumulative update, the problems are again present.

[sourcechord]

Hi, @Armin2208

Thanks for the information.
I fixed it in FluentWPF v0.8.0-alpha004
Please try it.

[Armin2208]

I've tried it and it works. Nice, thank you!

[sourcechord]

I'm glad to hear that.
I'll close this issue.
If you have any problems, please reopen this issue.

[NickAcPT]

I know that this issue has been closed already, but is there a way to keep the real acrylic blur and not have these issues?

For example, I've seen DevExpress avoid this issue by temporarily disabling the transparency when moving the window, showing the Fallback colour.

[tricky-mind]

@sourcechord , I actually know how to recreate the acrylic effect of uwp using interop(not the setWindowComposition() method but using the direct x)

But have the same issue. But only on resizing and not on dragging

Preview

This is totally different from your code.

[not-nullptr]

It is also worth mentioning that dragging the window on the desktop does not lag at all.

[sourcechord]

Hi @NotARobot6969

This is the intended behavior.
There are two types of blur effect;

• ACCENT_ENABLE_ACRYLICBLURBEHIND: Hard blur that is same as UWP's acrylic effect
• ACCENT_ENABLE_BLURBEHIND: Soft blur

ACCENT_ENABLE_ACRYLICBLURBEHIND effect causes laggy behavior during window is moving or resizing. So that, FluentWPF applies ACCENT_ENABLE_ACRYLICBLURBEHIND effect only when the window is stabled, and applies ACCENT_ENABLE_BLURBEHIND effect during window is moving or resizing.

[not-nullptr]

@sourcechord But then there is no blur for most of the time, at least for me.

[not-nullptr]

To clarify: For me, the laggy effect is applying when I move the window, and no effect is being applied when it's stationary.

[sourcechord]

According to the uploaded movie, the background of the window doesn't seems to have enough texture. It is difficult to recognize the blur effect.
Could you show the window on a more complex background images?

[not-nullptr]

To be clear, it's lagging when it is being dragged. @sourcechord
https://user-images.githubusercontent.com/62841684/124490002-837ab280-dda9-11eb-8314-147b7ffd798a.mp4

[sourcechord]

Please tell me your environment.
Your window has rounded border. Are you using windows11 insider preview?
I've not tested FluentWPF 0.10.0-alpha001 in windows11 yet 😓

[not-nullptr]

Indeed! I forgot to mention it.

[not-nullptr]

@sourcechord I forgot to tell you this too; the less windows behind the acrylic program, the less lag there is.

Desktop with no windows behind (smooth):
https://user-images.githubusercontent.com/62841684/124514339-b8e8c580-ddd4-11eb-873b-fc2f42053f53.mp4

Many windows behind (laggy):
https://user-images.githubusercontent.com/62841684/124514438-ecc3eb00-ddd4-11eb-98df-03fc8d108521.mp4

[Simnico99]

Seems to be a Windows 11 related issues as I am experiencing the same thing on Windows 11 Version 22000.51:

[alexmercerind]

Seems to be a Windows 11 related issues as I am experiencing the same thing on Windows 11 Version 22000.51

Latest build of Windows 11 22000.100, acrylic has stopped working. 😭
C'mon Microsoft.

[sourcechord]

I'm checking the window behavior with FluentWPF in Windows11 environment. But, currently there is no way to apply aclylic effect with SetWindowCompositionAttribute API.
So that I turnd off acrylic effect in FluentWPF 0.10.0-alpha002(only in Windows11 env).

It's a tough situation; however I'll continue to survey to provide 'Fluent Design' in windows11 environment.

[selastingeorge]

@sourcechord i am working on a workaround using direct composition, a sample win32 demo is available here : Acrylic Effect using DWM and Direct Composition. I am trying to build a wpf version, its a bit hard.

[alexmercerind]

@Extrimis I also tried to use similar approach but with XAML islands instead.
And those widgets always overlap the existing widgets. Can't figure out.

[selastingeorge]

@Extrimis I also tried to use similar approach but with XAML islands instead.
And those widgets always overlap the existing widgets. Can't figure out.

Create Separate window and attach both windows together with SetWindowPos(), instead of Resizing Both Windows, Resize the Windows.UI.Composition.Visual so there wont be any flickering on resize. The acrylic window should be WS_EX_TRANSPARENT,WS_EX_LAYERED

[selastingeorge]

@Extrimis I also tried to use similar approach but with XAML islands instead.
And those widgets always overlap the existing widgets. Can't figure out.

Create Separate window and attach both windows together with SetWindowPos(), instead of Resizing Both Windows, Resize the Windows.UI.Composition.Visual so there wont be any flickering on resize. The acrylic window should be WS_EX_TRANSPARENT,WS_EX_LAYERED

I am looking forward to mica than acrylic.

[sourcechord]

Hi, @Extrimis
Thanks for the information, it was very interesting. But it seems hard to implement in WPF.

I am looking forward to mica than acrylic.

I think so too. I'd like to introduce mica materials in FluentWPF, but haven't found a way to achieve it.

BTW FluentWPF currently has some problems in Windows11 that need to be fixed. So that, I created another GitHub issue(#130) to track it.
Please let me know about Windows 11 problems and acrylic effects in above issue.

[selastingeorge]

My laptop won't support windows 11 otherwise I would have checked it.

[selastingeorge]

Have you tried windows.ui.composition interop method for acrylic, that one won't lag but it has airspace issues that must be solved, it's the real acrylic

[sourcechord]

No, I heven't tried yet. Because it seems that Composition API doesn't support interop with WPF window.
I read following article, but there are only CompositionHostControl way, and no explanation for interop with WPF window.
https://docs.microsoft.com/en-us/windows/apps/desktop/modernize/using-the-visual-layer-with-wpf

[selastingeorge]

you don't need a compositionHostControl to do that,you can directly render those things into wpf window,but the only issue is the airspace issue,and the only way i see to solve the issue is by overlapping windows

[selastingeorge]

No, I heven't tried yet. Because it seems that Composition API doesn't support interop with WPF window.
I read following article, but there are only CompositionHostControl way, and no explanation for interop with WPF window.
https://docs.microsoft.com/en-us/windows/apps/desktop/modernize/using-the-visual-layer-with-wpf

Check out the microsoft repo : WPF AcrylicEffect Sample

[sourcechord]

OIC 😃
I tried WPF AcrylicEffect Sample, and recognized that can draw to window directly. But it has airspace issue as you said.
If we use Windows.UI.Composition, we have to create separete window for avoiding airspace issue.

It is difficult to implement, and causes the increase of complexity.
So that, I'll release FluentWPF 0.10.0 with SetWindowCompositionAttribute way, however continue to investigate real acrylic effect.

[selastingeorge]

Ok

…

On Wed, 11 Aug, 2021, 5:20 pm minami_SC, ***@***.***> wrote: OIC 😃 I tried WPF AcrylicEffect Sample <https://github.com/microsoft/Windows.UI.Composition-Win32-Samples/tree/master/dotnet/WPF/AcrylicEffect>, and recognized that can draw to window directly. But it has airspace issue as you said. If we use Windows.UI.Composition, we have to create separete window for avoiding airspace issue. It is difficult to implement, and causes the increase of complexity. So that, I'll release FluentWPF 0.10.0 with SetWindowCompositionAttribute way, however continue to investigate real acrylic effect. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#42 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ARKGWVKN4N4QEAVK3Y4EQBDT4JPXTANCNFSM4HHJS5PA> .

[gen3vra]

has anyone else observed the behavior that in visual studio 2022 the drag is fine in debug mode?

in my application which makes use of SetWindowCompositionAttribute() I've observed the following strange behavior:
In visual studio 2022 debug mode Acrylic blur windows seem to function as originally intended.
Additionally, attaching the visual studio 2022 debugger to the built application makes the faulty build work for as long as the debugger is attached.
This behavior persisted in both Net 6 and Net core 3.1, and Visual Studio 2019 did not “fix” the application as the video shows 2022 did.
Video of behavior:
https://streamable.com/recib9
(ShareX basically gives up recording the laggy drag movement bug)
Can anyone let me know if they’re also seeing this?