Extension|Author (truncated)|Version
---|---|---
html-snippets|abu|0.1.0
vscode-eslint|dba|1.3.2
python|don|0.7.0
vscode-html-css|ecm|0.1.8
php-debug|fel|1.11.1
php-intellisense|fel|1.5.1
php-pack|fel|1.0.1
cpptools|ms-|0.12.4
csharp|ms-|1.12.1
JavaScriptSnippets|xab|1.4.1
html-css-class-completion|Zig|1.10.0
Steps to Reproduce:
(Lag doesn't happen while in full-screen mode either)
Reproduces without extensions: Yes/No
Edit: Added the workaround:


Do you see the lag with extensions disabled? Run code --disable-extensions in the command line to test with extensions disabled
Yes, I've disabled all extensions and the lag persists. Going into full-screen mode fix it until I close code and open it again. I tried googling this problem and found that an user has reported the same issue since 2016.
This issue just about drove me to drink last year with my xps13. I thought it was the machine, it drove me so nuts. Same deal, go full screen and it clears up.
This would be again a dup of #13612
I have briefly investigated what the hell is going on upstream, I could find:
where Chromium instantiates a DirectManipulationHelper in their HWNDMessageHandler::Init method. -- https://cs.chromium.org/chromium/src/ui/views/win/hwnd_message_handler.cc?type=cs&q=DirectManipulationHelper&sq=package:chromium&l=419
I'm no Electron expert, but I'd expect Electron to also go through the same code path that initialize the window as a window which supports "direct manipulation".
@zcbenz Would you know if Electron is calling HWNDMessageHandler::Init ?
@alexandrudima HWNDMessageHandler::Init is called for every window, however DirectManipulationHelper seems to have been disabled in later versions of Chromium:
https://chromium.googlesource.com/chromium/src/+/20407a59ca3f29bfe7ca6a0cdea8fe95a7482ab5
You probably want to backport it to Electron.
I found an issue that seems to reference the issue in Chromium's issue list.
https://bugs.chromium.org/p/chromium/issues/detail?id=713907
It looks like the developers cannot replicate the problem. Everyone feel free to upvote it to get this thing fixed.
Does anyone know if it has been fixed in Windows 10 fall creators update? I know it's a problem with Chromium but just wondering if the update somehow fixed it.
@tahnik It's still an issue with FCU 16299.19. I don't think this is a windows problem, but part of the chromium code that vs code uses via Electron.
@wizarrc I don't know why this issue in Chromium is being ignored for this long. I can't use windows just because of this problem 馃槩
@tahnik umm, correct me if I'm wrong on the fact portion, and this is a very pointed opinion, but I think I have a good reason why they don't care. It's a Goggle operated project, it's a Windows related bug and it affects mostly dev related scenarios. If you ask them, they will tell you Windows is dead for developers and you should have moved to Linux or Mac a long time ago as a programmer. If I remember correctly, Google a long time ago forbid their employees from using Windows, so how can they possibly repo the issue.
This fix must come from outside Google proper. If I understood the Chromium code base I'd be the first to issue a PR cause this is such an annoying problem.
BTW, if this starts any kind of flame war I will retract my opinions.
@wizarrc Nope, I am not gonna start any wars. I get your point. The biggest problem for me is that it affects all the electron apps as well. If it was only chrome, I could get away with firefox quantum or even edge maybe. I just hope this gets fixed at some point :(
@tahnik yeah, we need a browser drop in replacement in electron like they do now for node.js so you can pick your own rendering engine.
@bpasero was able to reproduce in Chrome when starting Chrome from scratch from the command line via e.g. start https://www.github.com
The weird thing is that the issue goes away once a new tab is created in Chrome or (for us) once the window is resized (restore+maximize or resize via mouse).
IMHO there is a bug of some sorts in Chromium in https://cs.chromium.org/chromium/src/ui/views/win/hwnd_message_handler.cc , perhaps around WM_MOUSEWHEEL or WM_POINTERWHEEL and around how they manage and dispatch things to windows.
I also found that it doesn't lag when you scroll absolutely vertical on the trackpad, and it lags badly if your scrolling is far from vertical.
@taoyouh I tried out what you said, if I try to be absolutely vertical with two-finger scroll on the precision touchpad, I found that 1 out of 10 times it wont lag, but it's not as fast (scroll inertia?) as I'm used to. That might mean that 9 out of 10 times I am not perfectly vertical. I really have no way to measure how absolute I am. It could be that it has nothing to do with a precision touchpad and more that with normal touch pads, people don't notice because it's, well, not precise and registers as perfectly vertical, thus not triggering a different code path.
Hi, I am a developer from Chrome/input-dev currently working on support Windows Precision Touchpad. Just create an issue for it. I already start coding, hope it can fix this issue.
https://bugs.chromium.org/p/chromium/issues/detail?id=779372
@chaopeng just....thank you
I am experience lag when vertical scrolling too, but only in VSCode. I use other Electron apps like Discord and Slack and I cannot reproduce it there.
Where and how:
I took some CPU/Memory profiles
@bgadrian you might want to lock down your google share. There are books and videos unrelated that you might not want to share with everyone.
Most helpful comment
Hi, I am a developer from Chrome/input-dev currently working on support Windows Precision Touchpad. Just create an issue for it. I already start coding, hope it can fix this issue.
https://bugs.chromium.org/p/chromium/issues/detail?id=779372