Vscode-vibrancy: Problem drag, move window by Title Bar

Thanks for feedback and very sorry. I don't know how to fix this. I think this is a bug in windows.

I have run into this problem too

The acrylic effect will have a drag delay on the Electron window. If you use blur behind or transparent gradient, it will not appear.

In fact, I have never seen such problem in windows 10 1809.

This problem occurs in Windows 1903 and I don't know if it only appears in this version. (In fact, some interface errors have appeared in Windows 1903.)

I've only tried this on Windows 1903. Has anyone tried this extension on newer Insider versions of Windows? Interestingly, this issue doesn't seem to affect GPU or CPU usage.

I'm 1903 too and face this problem

Same problem on 1903

Same problem

+1

Same problem on 1903

Appears to be 1903 issue as I have no problem on 1809

+1

In #14 v1.0.6. The mouse lag still exists, I have tried many methods, and I can't solve the problem in 1903.

The problem is not in electron, and there is currently no perfect way to open the acrylic effect without UWP in 1903.

The mouse lag still exists in the latest Windows 10 insider preview.

Thanks for taking the time to look into this @EYHN. I wonder if there's a way to fool Windows into thinking VSCode/Electron is a UWP app.

I just came here to report this problem. Somewhat glad I'm not the only one having it.

On my pc at work, somewhat decent specs, Windows 1809 - moves with no lag whatsoever.
On my home pc, much better specs, Windows 1903, laggy as hell.

Many days have passed and this problem still there.
I have push the native code for windows at https://github.com/EYHN/vscode-vibrancy/tree/master/src/blur-cli .
Maybe you can help me if you know very well about windows

news: In window 10 1903, I found that reducing the "mouse rate" below the frame rate can effectively solve this problem.

I spent a few days researching this problem, and now I give up. It seems to be a problem inside DWM, the mouse polling rate is higher than the screen rate, causing the rendering request to block in the queue, and it looks like a mouse delay.

Don't worry, the same problem also appears in the Microsoft Office, thousands of Windows users are troubled by it, the following are some discussion:

https://answers.microsoft.com/en-us/msoffice/forum/all/why-does-my-excel-window-lag-so-much-when-moved/04b1fb97-b9da-481e-b37a-63257460c5b7

https://answers.microsoft.com/en-us/windows/forum/windows_10-performance/windows-10-mouse-lag-sluggish-window-dragging-in/12ab88a5-9e13-4d37-8f2d-106d56fcd775

There are now some methods:

• Use Windows 10 1809 and wait for Microsoft to fix the problem
• Close 'Show window contents while dragging'
  In the search box on the taskbar, type 'performance', then select 'Adjust the appearance and performance of Windows' in the list of results. On the 'Visual Effects' tab, Un-selecting 'Show window contents while dragging'.

• Reduce mouse polling rate
  In many gaming mouse driver panels can adjust the mouse polling rate.

    I will also provide a transparent only version, removing blur and compatibility with all operating systems and environments.

我花了好几天研究这个问题，现在我放弃了。看来是DWM内部的问题，鼠标回报率高于屏幕刷新率导致渲染请求阻塞在队列里，看起来就像鼠标延迟一样。

不要担心，同样的问题还出现在Office软件中，上千Windows用户受到其困扰，以下是一些讨论：

https://answers.microsoft.com/en-us/msoffice/forum/all/why-does-my-excel-window-lag-so-much-when-moved/04b1fb97-b9da-481e-b37a-63257460c5b7

https://answers.microsoft.com/en-us/windows/forum/windows_10-performance/windows-10-mouse-lag-sluggish-window-dragging-in/12ab88a5-9e13-4d37-8f2d-106d56fcd775

现在有几种备用方法：

• 使用 Windows 10 1809，然后等待微软修复问题
• 关闭 “拖动时显示窗口内容”
  在任务栏搜索性能，选择 “调整 Windows 外观和性能”, 在 “视觉效果” 选项卡关闭 “拖动时显示窗口内容”
• 降低鼠标回报率
  一般游戏鼠标驱动面板都可以调整鼠标回报率

之后我还会提供一个仅透明版本，去掉模糊效果并兼容所有操作系统和桌面环境。

@EYHN I think I found a solution.
In another electron app Terminus, they provide a setting "background type", and two type "Blur" and "Fluent", it calls a function this.electron.ipcRenderer.send('window-set-vibrancy', enable, type), and I found that "Fluent" works lag but "Blur" works well. I don't know how this.electron.ipcRenderer.send('window-set-vibrancy', enable, type) works, but I think this is a solution before MS fix it in DWM.

我安装了Aero Glass后在改对win10处理的代码让其调用dwm（即win7实现）部分运行在win10 1909拖动时窗口不会卡顿

我安装了Aero Glass后在改对win10处理的代码让其调用dwm（即win7实现）部分运行在win10 1909时时窗口不会卡顿

然而Aero Glass在win10 2004里不起作用

我安装了Aero Glass后在改对win10处理的代码让其调用dwm（即win7实现）部分运行在win10 1909时时窗口不会卡顿

然而Aero Glass在win10 2004里不起作用

从win10通用开发的调试包里取文件覆盖然后命令重建symbols也不行？

Another way is to put windows into power saving mode, which usually disables all transparency effects, but for some reason it fixes the lag 🤷‍♂️

似乎 Win 10 2004 版本 KB4541738 修复了此项问题。

你能提供详细解决办法吗，windows1909 还是有拖动延迟

奇怪，我之前运行 unpacked 都是正常的无延迟拖动，但现在又有延迟了……

似乎 Win 10 2004 版本 KB4541738 修复了此项问题。

😂awsome

你能提供详细解决办法吗，windows1909 还是有拖动延迟

1909直接用Aero Glass不行么？ps：需要修改该扩展代码

既然拖动有bug，能否通过提供毛玻璃特效的透明背景图片代替解决

Use EasyWindowDrag to move window can relieve this problem

For me dragging the window got impossible with this extension installed. The window is moving in slow motion. It is not a CPU/GPU resource problem.

This made VS code unusable. I had to uninstall this extension to use VS code again.

@Spenhouet Thank you for reminding us what this bug is. It's a Windows problem that comes as a result of using the Acrylic effect in such an unsupported way, and there aren't really any good solutions.

@Toby56 I was not sure if it is the same issue as OP described. It looks different to the GIF he provided.

@Spenhouet Yeah, the GIF isn't very clear, but it is as you described! It's a mouse polling issue, where as soon is you start dragging, the window goes slower than it should, and accumulates a massive delay between where it is and where it should be. Unfortunately, there is nothing you can do about it :(

So is this still an issue as of the latest Win10 releases? Don't want to install this if it will essentially break VSCode for me...

@iPyGuy Yeah basically, don't expect it to be fixed any time soon. It's not an official windows method.

似乎 Win 10 2004 版本 KB4541738 修复了此项问题。

这个补丁没有合并到正式的2004里面也没有发布到半年频道里吧

@EYHN @Toby56
Do you think this could be "fixed" by disabling the acrylic effect while the window is moved, as you (@Toby56) described here: https://github.com/23phy/ewc/issues/22#issuecomment-599448590 ?

Alternatively, do you think it'd be possible to disable "Show window contents while dragging" in performance settings only while VSCode is active/moved, by changing the related registry entry on the fly, on focus or move event? Not seeing window contents for all windows is pretty bad, but if that only affected VSCode I could live with the tradeoff 😅

@jonaskuske
Disabling the acrylic affect on drag probably is the best internal fix. It can be a but fiddly, but you can switch it to just transparency without any blur. Another factor that makes it more complicated, is that the acrylic breaks when enabling it from another blur effect in battery saver mode because acrylic is usually disabled in that mode? I can't remember. Because of this you have to reset the blur each time which can create a small white flash. There's no way to tell if it's in battery saver mode or not as far as I know and battery save wouldn't be very common. idk.

But it works for the most part and would be MUCH MUCH better than messing with the registry on the fly. For sure I don't think that doing that is practical.

@Toby56

the acrylic breaks when enabling it from another blur effect in battery saver mode because acrylic is usually disabled in that mode?

Yeah, Acrylic is usually disabled both in Energy Saver Mode and while a window isn't focused. So there usually is only one window with acrylic effects active, while the ones in the background display opaque.

There's no way to tell if it's in battery saver mode or not as far as I know and battery save wouldn't be very common. idk.

For me it is automatically enabled once I hit 20% battery, so I wouldn't say it's uncommon. But you can detect it!
It's possibe with the node bindings for the native Windows Runtime API:

const { PowerManager } = require('@nodert-win10/windows.system.power')

let energySaverEnabled = PowerManager.energySaverStatus === 2

PowerManager.on('energySaverStatusChanged', () => {
  energySaverEnabled = PowerManager.energySaverStatus === 2
})

@jonaskuske
That's great that you know a way to detect battery saver mode using NodeJS bindings to native Windows functions! That looks like a super simple way to solve some problems. This way we can write code that switches to "blur behind" usually, and to plain transparency on battery saver mode, eliminating the unnecessary white flash.

For this specific problem, I don't know how the code in this project is structured, will have to ask @EYHN if they want to implement something like this. Maybe I'll post a GIF of it in action.

@Toby56
I just realized that native dependencies are probably not an option in VSCode extensions, so while this solution should help everyone who wants to add the acrylic effect to their own Electron app (so they can compile it against their specific Electron/Node version), I don't know if it helps here :/

Would probably need to ship a separate pre-built binary instead of using the Node bindings, as this repository is already doing with blur-cli.exe 🤔

@jonaskuske
That's true! Didn't think of that. I have no idea how, but it could probably be build in to the C++ part that is compiled into the binary??? I really don't know the limitations of VSCode extensions.

Definitely useful for my own app tho 😀!

Right, that should probably work. Unfortunately I don't really know anything about C++ either (other than the little that is needed to program Arduinos) :/

Anyway if this is implemented it should definitely be optional, as folks with e.g. 144Hz monitors can have vibrancy during window movement if they set their mouse sample rate to something like 125, which should still be fast enough for everyday use.

@quank123wip @EYHN
Yes, I found it too.
Acrylic background in terminus have two options:

Blur have no problem, And Fluent have lag issue too.

So I think this is the answer.

No sure if that is of any help but the Window Terminal has a working transparency effect. They call it "Acrylic".
The Terminal does not build on electron... it is implemented in C++.

You can also change the opacity:

Maybe looking at their implementation can help:

https://github.com/microsoft/terminal/blob/master/src/cascadia/TerminalControl/TermControl.cpp#L376

@Spenhouet Yeah, sorry but that doesn't really help us much. The open source Windows Terminal as well as many many other apps use this effect (always called acrylic), but they are dedicated windows apps and can do the "official" way, which will work out-of-the-box. However what we are doing, is putting something where it really was never intended to go, which is why it has bugs that won't be fixed

@Jinhaihan Yes, true, we can just make it blur like that, and it doesn't have the problem! Maybe we should. But imo it doesn't look nearly as nice as the "fluent" acrylic effect. I think it's an old effect used in Windows 7 (Aero), or something like that. The blur radius is not as much, and it doesn't have the fluent Windows 10 "acrylic" texture, as well as the other layers that go into making the acrylic blur look nice.

Having an option like Terminus does is perfectly possible, and maybe a solution many would be happy with.

@Toby56 That might be a dumm question: Is it impossible to go the "official" way?

@Spenhouet Maybe, if you feel like rewriting VS Code from the ground up. Otherwise, probably not.

I don't actually know a whole lot about how the acrylic effect is applied to a chromium window using Node JS and C++. But VS Code is and will always be made in Electron, and there is no officially supported way of doing this. I'm pretty amazed that this method works at all. So unless some genius finds another way, then we're stuck like this.

@Toby56 Okay, makes sense.

I guess the acrylic effect will be more present in Windows in the future. VS code will probably adopt that in this distant future.

@Spenhouet
Yep, currently the Acrylic effect is a feature of XAML, the UI framework that only modern Windows apps (the type you typically see in the Microsoft Store) can use. That's why it's no problem for Windows Terminal and others. "Old-school" applications can use most of the modern APIs, but not those that rely on rendering, views etc.
I don't know either how the hack in this repo actually works, but it's definitely a hack 😃

However, with the upcoming WinUI 3 (part of Project Reunion, Microsoft's attempt to unify old and modern APIs) we'll get a feature called "XAML Islands", which allows usage of modern UI in traditional applications. Then it should be possible to add Acrylic without hacks, maybe even as direct feature of Electron itself. 🙏🏻

@jonaskuske Wow that's pretty cool, didn't know Microsoft were planning something like this!!! Some things like tray icons are not possible for UWP apps without packaging a companion Win32 application.

I am glad to report that Windows 10 Insider Preview (build 20161) fixed the issue for me.

@LegoLivesMatter That's fantastic to hear! I should move to the fast insider channel to verify this.

@Toby56 Good luck!

@jonaskuske @LegoLivesMatter @racoonx2p @EYHN

I can confirm that it is fixed in build 20161!
Well mostly...

I say mostly because, while it is great and completely usable now, it is a tiny bit quirky. Resizing still has this issue for me, which is annoying, but probably not an issue for anyone, unless you find yourself resizing a lot. Short quick resizes is fine.

Boy, does it look good tho:

I have dual monitors, and the same issue too. Also, if the window is close to an edge of any of the monitors, a small part of that edge becomes translucent without blur. Still better than nothing!

I have also noticed that when the VS Code window is maximized on the secondary monitor, the blur disappears but the acrylic "filter" stays there. From what I can tell this is a consequence of the window slightly "reaching" the other monitor. This doesn't happen when the VS Code window isn't focused or when it's maximized on the primary monitor.

@LegoLivesMatter Yeah I had this problem too, forgot to mention it. So stupid, but windows often reach into the next monitor, and this is obviously the cause. Cross our fingers and maybe it'll get fixed. Hopefully both the effect breaking and window crossing!

For some reason using a theme with Stardock WindowBlinds actually resolves this issue as well. It must be doing something with window manager compositing but no idea what. There's a quick flicker when maximizing the window but otherwise it's good.

I installed windows-insider dev-channel, and the dragging is fine. However, resizing still poses issues. I've also noticed the my 64 bit winforms-app using this method has this issue, but not the 32 bit version. Also, I have a WPF test app that is 32 & 64 bit while using SetWindowCompositionAttribute, and it resizes OK. Also, Avalonia resizes OK.

Use EasyWindowDrag(KDE style).ahk can alleviate this problem

https://www.autohotkey.com/
https://lexikos.github.io/v2/docs/scripts/~~