Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Problem drag, move window by Title Bar #5

Closed
aka-raccoon opened this issue Jul 19, 2019 · 75 comments
Closed

Problem drag, move window by Title Bar #5

aka-raccoon opened this issue Jul 19, 2019 · 75 comments

Comments

@aka-raccoon
Copy link

@aka-raccoon aka-raccoon commented Jul 19, 2019

Hello,

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

b5IPZOAbeZ

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

@EYHN
Copy link
Owner

@EYHN EYHN commented Jul 20, 2019

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

@TTTPOB
Copy link

@TTTPOB TTTPOB commented Jul 23, 2019

I have run into this problem too

@syfxlin
Copy link

@syfxlin syfxlin commented Aug 2, 2019

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
Copy link
Owner

@EYHN EYHN commented Aug 2, 2019

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

@syfxlin
Copy link

@syfxlin syfxlin commented Aug 2, 2019

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
Copy link

@mkanet mkanet commented Aug 3, 2019

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
Copy link

@Himself65 Himself65 commented Aug 3, 2019

I'm 1903 too and face this problem

@huyinjie
Copy link

@huyinjie huyinjie commented Aug 3, 2019

Same problem on 1903

@lonelyion
Copy link

@lonelyion lonelyion commented Aug 3, 2019

Same problem

@CircuitLord
Copy link

@CircuitLord CircuitLord commented Aug 3, 2019

+1

@gamesgao
Copy link

@gamesgao gamesgao commented Aug 5, 2019

Same problem on 1903

@amrbashir
Copy link

@amrbashir amrbashir commented Aug 8, 2019

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

@Sominemo
Copy link

@Sominemo Sominemo commented Aug 13, 2019

+1

@EYHN
Copy link
Owner

@EYHN EYHN commented Aug 14, 2019

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
Copy link

@mkanet mkanet commented Aug 14, 2019

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
Copy link

@tenF tenF commented Aug 16, 2019

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
Copy link
Owner

@EYHN EYHN commented Sep 7, 2019

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
Copy link
Owner

@EYHN EYHN commented Oct 18, 2019

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

@EYHN
Copy link
Owner

@EYHN EYHN commented Oct 26, 2019

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
Copy link

@quank123wip quank123wip commented Feb 18, 2020

@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
Copy link

@huhuime huhuime commented Feb 28, 2020

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

@slacksoft
Copy link

@slacksoft slacksoft commented Mar 6, 2020

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

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

@huhuime
Copy link

@huhuime huhuime commented Mar 10, 2020

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

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

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

@Toby56
Copy link

@Toby56 Toby56 commented Mar 12, 2020

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

@Spenhouet
Copy link

@Spenhouet Spenhouet commented Jun 24, 2020

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

@Toby56
Copy link

@Toby56 Toby56 commented Jun 24, 2020

@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
Copy link

@Spenhouet Spenhouet commented Jun 24, 2020

@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
Copy link

@jonaskuske jonaskuske commented Jun 24, 2020

@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
Copy link

@Toby56 Toby56 commented Jun 24, 2020

@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
Copy link

@LegoLivesMatter LegoLivesMatter commented Jul 4, 2020

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

@Toby56
Copy link

@Toby56 Toby56 commented Jul 4, 2020

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

@LegoLivesMatter
Copy link

@LegoLivesMatter LegoLivesMatter commented Jul 4, 2020

@Toby56 Good luck!

@Toby56
Copy link

@Toby56 Toby56 commented Jul 6, 2020

@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:
image

@LegoLivesMatter
Copy link

@LegoLivesMatter LegoLivesMatter commented Jul 6, 2020

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
Copy link

@LegoLivesMatter LegoLivesMatter commented Jul 6, 2020

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
Copy link

@Toby56 Toby56 commented Jul 6, 2020

@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
Copy link

@xenobrain xenobrain commented Jul 9, 2020

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
Copy link

@VS-ux VS-ux commented Jul 24, 2020

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.

@backtolife2021
Copy link

@backtolife2021 backtolife2021 commented Jul 25, 2020

@VS-ux
Copy link

@VS-ux VS-ux commented Jul 25, 2020

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.

@backtolife2021
Copy link

@backtolife2021 backtolife2021 commented Aug 22, 2020

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

@tims-j
Copy link

@tims-j tims-j commented Sep 30, 2020

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

@ziggythehamster
Copy link

@ziggythehamster ziggythehamster commented Oct 19, 2020

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
Copy link

@ziggythehamster ziggythehamster commented Oct 19, 2020

@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
Copy link

@Y7000-save-me Y7000-save-me commented Nov 20, 2020

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

@mkanet
Copy link

@mkanet mkanet commented Dec 13, 2020

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

Screenshot

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
Copy link

@lemonnuggets lemonnuggets commented Jan 16, 2021

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
Copy link

@lonelyion lonelyion commented Jan 26, 2021

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
Copy link
Owner

@EYHN EYHN commented Jan 26, 2021

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

@EYHN EYHN closed this as completed Jan 26, 2021
@mkanet
Copy link

@mkanet mkanet commented Jan 26, 2021

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests