EYHN / vscode-vibrancy

Enable Acrylic/Glass effect for your VS Code.
MIT License
561 stars 37 forks source link

Problem drag, move window by Title Bar #5

Closed aka-raccoon closed 3 years ago

aka-raccoon commented 5 years ago

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 commented 5 years ago

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

TTTPOB commented 5 years ago

I have run into this problem too

syfxlin commented 5 years ago

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 commented 5 years ago

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

syfxlin commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

I'm 1903 too and face this problem

huyinjie commented 5 years ago

Same problem on 1903

lonelyion commented 5 years ago

Same problem

CircuitLord commented 5 years ago

+1

gamesgao commented 5 years ago

Same problem on 1903

amrbashir commented 5 years ago

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

Sominemo commented 5 years ago

+1

EYHN commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

EYHN commented 5 years ago

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:

  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

现在有几种备用方法:

quank123wip commented 4 years ago

@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 commented 4 years ago

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

slacksoft commented 4 years ago

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

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

huhuime commented 4 years ago

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

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

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

Toby56 commented 4 years ago

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

reycn commented 4 years ago

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

CatNofishing commented 4 years ago

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

reycn commented 4 years ago

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

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

CatNofishing commented 4 years ago

😂awsome

huhuime commented 4 years ago

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

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

CatNofishing commented 4 years ago

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

I-Want-ToBelieve commented 4 years ago

Use EasyWindowDrag to move window can relieve this problem

Spenhouet commented 4 years ago

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.

Toby56 commented 4 years ago

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

Spenhouet commented 4 years ago

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

Toby56 commented 4 years ago

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

iPyGuy commented 4 years ago

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

Toby56 commented 4 years ago

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

huhuime commented 4 years ago

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

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

jonaskuske commented 4 years ago

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

Toby56 commented 4 years ago

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

jonaskuske commented 4 years ago

@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
})
Toby56 commented 4 years ago

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

jonaskuske commented 4 years ago

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

Toby56 commented 4 years ago

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

jonaskuske commented 4 years ago

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.

MortalKim commented 4 years ago

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

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

So I think this is the answer.

Spenhouet commented 4 years ago

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

image

You can also change the opacity:

image

Maybe looking at their implementation can help:

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

Toby56 commented 4 years ago

@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

Toby56 commented 4 years ago

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

Spenhouet commented 4 years ago

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