Problem drag, move window by Title Bar

[aka-raccoon]

Hello,

There seems to be a bug with moving window in Windows 10. After disabling vibrancy and restart VSC moving window works as expected.

Btw. Thank you very much for this plugin. I really appreciate it.

[EYHN]

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

[TTTPOB]

I have run into this problem too

[syfxlin]

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

[EYHN]

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

[syfxlin]

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

[mkanet]

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.

[himself65]

I'm 1903 too and face this problem

[huyinjie]

Same problem on 1903

[lonelyion]

Same problem

[CircuitLord]

+1

[gamesgao]

Same problem on 1903

[amrbashir]

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

[Sominemo]

+1

[EYHN]

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.

[mkanet]

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.

[tenF]

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.

[EYHN]

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

[EYHN]

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

[EYHN]

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 外观和性能”, 在 “视觉效果” 选项卡关闭 “拖动时显示窗口内容”
• 降低鼠标回报率
  一般游戏鼠标驱动面板都可以调整鼠标回报率

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

[quank123wip]

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

[huhuime]

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

[slacksoft]

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

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

[huhuime]

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

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

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

[Toby56]

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

[Toby56]

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

[Spenhouet]

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

[jonaskuske]

@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. 🙏🏻

[Toby56]

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

[LegoLivesMatter]

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

[Toby56]

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

[LegoLivesMatter]

@Toby56 Good luck!

[Toby56]

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

Something that I noticed that's not really related...

Something that I noticed that's not really related, and I don't know if this is a new issue or not, is that the blur and colour-filtering elements of the acrylic effect can disappear sometimes for certain reasons on my dual-display setup. If the window is dragged between displays, so that it is on both at the same time, the effect will only render properly on one of the displays, on the other it'll just be dark transparent with the texture (which doesn't look too bad). Sometimes it can flicker a lot. I can't capture it in a screenshot. It can also break this way temporarily at other random times. It's okay because it only happens under certain conditions, but it's weird.

Boy, does it look good tho:

[LegoLivesMatter]

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!

[LegoLivesMatter]

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.

[Toby56]

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

[xenobrain]

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.

[VS-ux]

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.

[I-Want-ToBelieve]

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

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

https://autohotkey.com/board/topic/22565-updated-easywindowdrag-kdeahk-with-added-control-support/

[VS-ux]

Thanks for your reply, but I stated that I didn't have issues with dragging (ie. moving the window) on the insider-dev channel, but had issues resizing on 64-bit app.

[I-Want-ToBelieve]

This seems to have been fixed on the version of Windows I'm using now.
I found this out all of a sudden, so I'm not sure if it's this version.

[tims-j]

@doublethinkio I'm on windows 10 build 19042.541 and still have the issue?

[ziggythehamster]

20H2 build 19042.572 here and also it still happens, so I think something that @doublethinkio has going specifically has made it work correctly. For me, dragging works and is smooth, it's just very very slow. That's different from some people where it's both slow and not smooth.

[ziggythehamster]

@jinhaihan mentioned that Blur works for them in Terminus and Fluent has the same issue in this comment. I did like 5 minutes of research and it appears that "Blur" maps to option 3, called ACCENT_ENABLE_BLURBEHIND in this project's blur-cli and "Fluent" maps to option 4, called ACCENT_ENABLE_ACRYLIC in blur-cli. This isn't configurable, and instead ACCENT_ENABLE_ACRYLIC (actually called ACCENT_ENABLE_ACRYLICBLURBEHIND in the API) is always chosen.

Making this configurable would be pretty trivial, but I don't have a Visual C++ toolchain set up to be able to build a new blur-cli.

[Y7000-save-me]

怎么删除毛玻璃效果，我卸载插件，删除配置。 还是没用

[mkanet]

@doublethinkio, thanks for providing a workaround. I tried executing EasyWindowDrag.ahk with autohotkey.exe. Unfortunately, I get the below error. I don't have any issues executing other AutoHotkey scripts.

Even if I use the original script I downloaded directly from:
https://lexikos.github.io/v2/docs/scripts/EasyWindowDrag.ahk

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

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

; Easy Window Dragging -- KDE style (based on the v1 script by Jonny) 
; https://www.autohotkey.com
; This script makes it much easier to move or resize a window: 1) Hold down
; the ALT key and LEFT-click anywhere inside a window to drag it to a new
; location; 2) Hold down ALT and RIGHT-click-drag anywhere inside a window
; to easily resize it; 3) Press ALT twice, but before releasing it the second

[lemonnuggets]

Not really sure if this helps but here's a project that looks like it might help with the problem.
Seo-Rii/electron-acrylic-window

[lonelyion]

I found that setting the backgroud of Terminus (eugeny/terminus 1.0.127) into Fluent, it will set the background as non-transparent when dragging the window. After stoping or temporarily staying, the window restore fluent background. The lag will not appear.

Maybe this is a good workaround for the project.

[EYHN]

The latest version (v1.0.10) contains a solution to the mouse lag, please see here for details.

[mkanet]

EDIT: I just tried the fix. It's definitely faster, even on 60hz! Thank you!!!