Did not see this on my VM, assignig to @Tyriar to check if he also sees it on his linux so we assess how serios it is

I don't have my Linux laptop with me at the moment, I'll mark this October to remind me. /cc @alexandrudima

I have this to, though it isn't present everywhere. The tree view panel and all the editors no longer smooth scroll, but entries which (I assume) are probably using browser rendering, like extension detail pages, do still smooth scroll.

running:
arch linux - x86_64 Linux 4.7.6-1-ARCH
GNOME Shell 3.22.1

I can't tell a different on either the tree view or the editor comparing 1.6.0 and 1.5.3 using Ubuntu 16.04. @bpasero @alexandrudima any ideas?

Dup of https://github.com/Microsoft/vscode/issues/12637

I don't believe this is a dup of that issue, that issue indicates it doesn't work at all, whereas this issue is purely related to smooth scrolling: 2-finger scrolling works, but acts like regular 'jumpy' scrolling.

I agree with @jshap70, this is a different issue as he described.

I think this is a regression in Chromium (I also noticed it there) which was fixed for me in 54.

Can confirm this, using two-finger scrolling for the editor is laggy. Using version 1.6.1 on my Windows 10 machine.

AFAIK we had no changes in the scroll handling logic, but we did update to a newer electron version (that includes Chromium 52).

It would be interesting to find out if Chrome 52 also suffers from this issue. We have the exact same scrolling code in the editor https://microsoft.github.io/monaco-editor/ so if anyone would like to try it and report here the findings, I would be thankful.

There are plenty of touchpads issues on Chromium: https://bugs.chromium.org/p/chromium/issues/list?can=2&q=touchpad

Are we hitting a known issue for them?

The scrolling in monaco is smooth and feels just like vscode did before for me inside Chrome (beta) 55.0.2883.21 as well as Chromium 54.0.2840.71.
I just built a version of Chromium 52.0.2743.85 to test, and can confirm that it has the same jumpy scrolling. Using monaco inside of it is especially rough. This confirms the idea that it's probably an electron bug and not a vscode bug. bummer.

@jshap70 Thank you very much for confirming this is a Chromium bug that will get fixed once we get a newer version. fyi @bpasero

I've also experienced this today on my Surface Book. It is a real bummer. Most weird, after using a mouse for a bit, the trackpad was working normally again. I'm sorry there's nothing I can do on our side, we get mousewheel events and respect them when we get them.

Electron did not yet adopt Chrome 54 but it is on their plan.

@jshap70 is the fix included in Chrome 53 or 54?

@bpasero I just built a copy of Chromium 53.0.2785.92, the highest 53 I had available, and it still had the choppy scrolling issue when using monaco. So 54 is the first version it is fixed on.

I was playing with this one for a while. Testing with a Lenovo Yoga 910 (Kaby Lake) -- Windows 10 Pro.

During my testing, I discovered that the lag occurs if you start VS Code maximized. I thought maybe I was going crazy, but all I did was restore the window and then re-maximize it and all of the scroll jank was gone.

Just to make sure I wasn't losing my marbles, I had my wife blind test it. It was a night and day difference. Hopefully this helps pinpoint the issue, I will be diving in to give it a shot myself tonight or tomorrow.

I have the same scrolling issue on Lenovo Yoga 910.
After resizing the window scrolling is smooth again.

I have a Surface 4 Pro and experience the same issue. Resizing the window fixes the scrolling.

I should probably mention that the issue I've been tracking through chromium is only present for me on my Lenovo W530 thinkpad in Linux, not Windows, and it is not solved by resizing the window. That might be different issue entirely.
Can someone who is having those issues try installing a version of chrome or chromium 52 or 53 and checking if monaco has the same issue?

I am having this issue on my SurfacePro4. Using the touchpad causes the editor to lag when scrolling if the window is full sized. If I resize the window so I can see my desktop a bit, the issue goes away.

Same issue happening for me using Win 10 and a new Surface Book. Can cofirm that resizing the window and remaximizing seems to resolve it (at least so far.)

I'm currently on the latest version with my Dell XPS 15 9550 (Touchscreen Version, Win10 x64) and I'm experiencing this exact problem. Didn't even know that it doesn't occur when I use the touchscreen scroll, only with the touchpad.

The resize / maximize trick fixes it at least a bit.

Same issue as here. Surface Book / Windows 10, but re-maximizing solves. Would be great not to have to every time I open VS Code.

Since Chromium 54 has been integrated into Electron, maybe VSCode can switch to the new Electron to definitely solve the problem ?

There is still no Electron release with Chrome 54 out.

Electron release with Chrome 54 is supposed to happen in January

From electron/pull/8406

(...) Going to release this as a beta 1.5.0 to npm now

Is there someway to be notified when Insiders will update to the new Electron?

I am waiting for the new Electron too. Having such a beautiful screen & editor plagued with terrible scrolling is too bad.

This issue exists also on late 2016's Dell XPS 13 9360 QHD. Noticed that only the touchpad (Windows Precision drivers) is affected while scrolling with the touch screen works well.

This still appears to be an issue in 1.10.2 (Dell XPS 15, touch screen is smooth)

So what's the problem now? It was indicated that this should have been fixed in January.

I'll like to reiterate my previous comment that this specific issue is not really tracking the issue on windows, as the information I posted about scrolling being broken in chromium was related to linux.
That said, the issue is still present on the current version of vscode

We can develop custom smooth scroll like in atom and it related too with https://github.com/Microsoft/vscode/issues/21359

@pixieaka currently code uses chrome's native scrolling, which in my personal opinion is much better than anything that is built on top of it when it works properly. Furthermore, the scrolling is fixed and works properly when done in monaco on more current versions of chrome (see here), which is why it's known to be an electron issue. So there's no real need to rewrite it since it's not code's issue.

They just need to wait for electron to update to Chromium 54, which I believe can be tracked here

@jshap70 Electron v1.6.2 released already with Chromium (56.0.2924.87) 16 days ago

@jshap70 https://github.com/Microsoft/vscode/issues/11953 This is build with latest Electron 1.6.2 with Chromium (56.0.2924.87) for Windows here: https://az764295.vo.msecnd.net/insider/d42d4467e681308a5f82b61cb11ee6b91f1b9864/VSCode-win32-1.11.0-insider.zip

But the problem with scroll is not solved yet

@pixieaka which problem with scrolling? this issue is for scrolling on linux, not windows

@jshap70 https://github.com/Microsoft/vscode/issues/20840 I have same issue with dell laptop on Windows 10. The scroll is very jumpy with track-pad.

@pixieaka might be related to the lag scroll in windows. I'm having the same issue here. https://github.com/Microsoft/vscode/issues/20348#issuecomment-291060102

This is driving me nuts, have to restore/maximize every minute while working. Any updates on this?

Todays VS Code insider build comes with Electron 1.6.x, would be interesting to hear if this update solves this issue for anyone: http://code.visualstudio.com/Download#insiders

@bpasero I don't think that link works, should it be https://code.visualstudio.com/insiders instead?
I'll check it out when I get a chance and let you know.

@bpasero I'm happy to say that smooth scrolling is back in the newest insiders build! on linux, that is.

Cool thanks!

On my Dell XPS 13 SkyLake, Precision TouchPad, Windows 10 @ 125% scaling, still exhibits the same issue for todays insider build a5e9d3

Some more info:

The screen seems to only refresh on scoll-end. So 2 finger scroll... (looks like nothing happened/frozen)
then lift fingers <- screen updates.

Sorry for double comment, but I found using "--disable-gpu" makes scrolling super smooth again for me.

Thanks to https://github.com/Microsoft/vscode/issues/14716#issuecomment-293120446 for the tip.

Is there any way to make this flag always be on, even when launching code from the context menu?
Edit: Seems not

Having a way to run Code with specific parameters would be a good idea (what about startup.json in ~ that would be used for command line parameters?) but I'd rather see the gpu-related problem fixed.

What is wrong with creating a global shell script that runs code --disable-gpu?

There is nothing wrong with having a global shortcut. But disabling the gpu to workaround a bug isn't very good if you ask me. Using the GPU instead of the CPU for rendering/scrolling can have a big impact on battery, performance, etc..

Just tested on xps, seems very promising! On a clean install first impression is pretty smooth. Will need to see how it is with all the addons but there's hope now.

Can confirm, Dell XPS 15 9560 + Windows 10 Creators Update, --disable-gpu works as a workaround.

still not smooth on surface book, even run --disable-gpu

I confirm it's not smooth on Surface Book (creators update): it doesn't jump so much anymore, but it's quite laggy.

Does anyone in the core Code team got such device or is everyone working on Mac? :)

@warpdesign I'm on a Surface Book. My workaround is to "restore" and "maximize" the VS Code window once after I open it. The two-finger scrolling on the trackpad then becomes smooth for me.

I've started a wiki page to collect/summarize reported information on this issue -- https://github.com/Microsoft/vscode/wiki/Known-issues

Disable gpu does not work on xps 15", minimize/maximize works but only for a short bit, have to keep doing it. Still the same issue in latest release.

@vladkosarev works for me, have you tried updating to the latest Intel graphics driver from their website?

Not sure if it has been mentioned, but this is an Electron issue. Same thing happens to me in the Slack desktop client.

I have the issue too, on an ASUS Zenbook laptop. Unmaximizing (and re-maximizing) seems to fix the issue temporarily.

• VSCode Version: Code 1.12.1 (f6868fce3eeb16663840eb82123369dec6077a9b, 2017-05-04T21:26:50.689Z)
• OS Version: Windows_NT ia32 10.0.14393
• Extensions:

|Extension|Author|Version|
|---|---|---|
|EditorConfig|EditorConfig|0.9.3|
|CppSnippets|hars|0.0.9|
|tabsanity|jedmao|0.0.9|
|contextualduplicate|lafe|0.2.0|
|cpptools|ms-vscode|0.11.0|
|trailing-spaces|shardulm94|0.2.11|
|vscode-fileutils|sleistner|2.5.1|
|ninja|surajbarkale|0.0.1|;

I have the same problem on my Dell XPS 9560. I have found a strange workaround

Right click on taskbar and select taskbar settings
Change taskbar orientation to the opposite of whatever it is at the moment, ie, If Bottom then set to Top or vice versa. If Left then Right etc
Change the taskbar back to the original orientation or leave it as it is, doesn't matter.
Smooth scrolling again
I have to do this every time I start VS Code but it works.

Also experiencing the issue. Minimize/maximize trick helps but sure is annoying. Unfortunately, no recent info regarding the issue in Electron's repo.

Laptop: Dell XPS 9560
OS: Win 10 Pro 10.0.15063
VS Code: 1.12.2

Same issue here with an Acer Nitro 15.

Laptop: Acer V Nitro 15
OS: Win 10 Pro
VS Code: 1.14.0-insider

Same issue here on Acer. Restore/Maximum code window and two finger scrolling works again.

Laptop: Acer Aspire F5-573
OS: Win 10 Home 1703
VS Code: 1.13.0

Upgraded VS code to insiders build 1.14.0 and problem remains.

Can be resolved by either restore/maximise window or running code with --disable-gpu.

Same issue on Surface pro 4.(I5, 8GB,256G) .
OS: Win 10 Home 1703
VS Code: 1.13.0
Can be resolved by resizing window.

Not sure if it'll help or not but I found this ridiculously detailed article on scrolling :) https://pavelfatin.com/scrolling-with-pleasure/

Same issue here.
OS: Win 10 pro build 14393
VS code: 1.13.1

I think it related to the OS. The integrated apps within Win 10 are not supporting TrackPoint scroll so well, the code may use some lib within the OS.

quick temporary workaround: Win+DOWN, Win+UP

I'm on insiders, Surface Book (i5 8gb model), scroll is extremely laggy.

How about someone from the VSCode team gets access to a Surface Book (or any precision touch pad) and definitely see what's wrong and a proper fix (or workaround) is given?

Surface devices are Microsoft's flagship machines for Windows 10: it gets me mad that VSCode performance is so bad on such a beautfiful machine (in addition for preventing me from doing any serious work on it using VSCode).

@warpdesign Some of the VSCode team have Surface devices and they are aware of the issue (see upthread). While very irritating, it's an upstream problem that no-one is yet able to solve.

I'm not too sure someones actually working on that though.. I think Electron is just saying it's an Chrome issue, but I was not able to find a bug in the issue tracker, except this one, which has basically no activity at all going on.. Does anybody know if someone is working on this?

It's happening for me as well on my 4k XPS 9550 and it's driving me nuts. I love VS Code so much, but having to minimize/maximize it every 5 minutes is so annoying...

https://bugs.chromium.org/p/chromium/issues/detail?id=713907

@tobiasviehweger It's no surprise it's still there :(

Can the problem be reproduced on Chrome with Monaco? Or is it specific to VSCode+Electron?

Scrolling choppy and basically useless on Dell XPS13 / Windows 10 until tried the --disable-gpu trick. Not ideal. Any sign of Electron moving to more recent Chromium?

+1 suffering from the problem here.
I've actually bought Surface Book because of great touchpad and keyboard, and mostly for work, so it's a critical issue for me, I'm considering returning Surface Book and buying mac again :(
My VSCode version:

Another piece of data:
On my old Mac Air 11" (with Win 10 installed, not macosx) touchpad works great in VSCode.
Version:

Fix pls?

Some more details.

What exactly happens on my Surface Book is that when I swipe up/down with two fingers:

• most of the time, it scrolls, but  after a 1 second lag
• sometimes nothing happens at all, as if the event didn't make it to VSCode
• some rare times, scrolling will happen right on time

As you can see this is highly unreliable and makes VSCode unusable on such devices.

I wanted to see what happened with the DOM events but the second I opened up the devtools, scrolling started working as expected, that is to say without the 1 second lag and on every swipe. This makes it difficult to help track the problem.

@kokajambo @Deiru2k is that what you are experiencing too?

I've found that: just showing or hiding the main menu works the same as resizing the window. So if you normally have the menu hidden, a quick 2 taps on the alt key when the scrolling becomes janky will make it smooth again for a while..

Did electron ever get updated?

Yes, we updated Electron multiple times since this issue was first reported. At the time the issue was reported, we were using an Electron version built on Chromium 52. We are now on Chromium 56, while the Chrome browser is on Chromium 60.

The upstream issues:
Electron: https://github.com/electron/electron/issues/8960 (closed in favour of the Chromium issue)
Chromium: https://bugs.chromium.org/p/chromium/issues/detail?id=713907 (the Chromium issue owner could not reproduce with Chromium 58)

If we are to be optimists, once we update to an Electron version built on Chromium >=58 this issue should be fixed.

If the issue is not fixed, we would need to ask for more help from our Electron friends, as it might be an indication that this is an Electron specific issue.

In the meantime, the workaround continues to work (resize the window once after having it opened).

I`m having this issue too.
VSCode Version: Code 1.14.2 (cb82feb, 2017-07-19T23:34:09.706Z)
OS Version: Windows_NT ia32 10.0.15063

using code --disable-gpu solved the problem

I can confirm this problem on my razer stealth, which minimize/maximize fixes it for some time.

@IanNS333 Same here, with Dell XPS 13 (9350).

This seems worse after the recent update.

It used to be choppy but would go away if i resized the window and maximized it again as others have now stated. It now just doesn't scroll at all. The window itself seems to "bounce" slightly when two finder scrolling.

Using a Samsung Notebook 9

I just bumped into this issue on a ASUS UX501JW and did some research.

Description of the issue: The scroll works on each version when I run Chrome or Electron normally, if I run as administrator none of the versions tested works.

Versions tested:
-- Chrome 62 (Stand alone browser, canary)
-- Chrome 60 (Stand alone browser)
-- Chrome 58 (Electron 1.7.5)
-- Chrome 56 (Electron 1.6.6)
-- Chrome 54 (Stand alone browser)
-- Chrome 51 (Stand alone browser)

OS: Windows 10

This bug is not in either VS-code or Electron, but rather in Chrome or how touch utils are written. Just wanted to add some info regarding my findings that for ASUS laptops there is no light in the tunnel.

Speaking of ASUS laptops (UX360CAK here) and Windows 10, the scrolling system-wide has been very glitchy for me the last month or so. E.g. when I momentum-scroll down a page (Chrome) or a list of items (Thunderbird, but not File Explorer), the scroll position will reset to the top of the list at random.

Another thing is that I had to turn off pinch-zoom because the amount of false detections was unbearable - yet I never had problems with this before. Coming back to a Macbook Pro trackpad was like some kind of religious revelation.

(Edit: deleted my post about the asus utility uninstall and native windows touchpad driver rollback as neither of these seems to have solved the issues with the quirkiness and possibly (tbd) vscode)

@youurayy Yep, Dell XPS 13 and delighted that I found how to turn off pinch to zoom as it was driving me mad.

@youurayy I figured out a workaround for scroll not working when running Chrome / Electron as administrator on ASUS laptops.

Work around:

• Kill the ASUS Smart Gesture applications in the task manager,
• Restart the Smart Gesture apps with run as administrator (AsusTPCenter.exe, AsusTPHelper.exe, AsusTPLoader.exe)

An educated guess is that this issue has it's roots in two things:

• ASUS Smart Gestures is probably sending their touch events in some odd way to other windows, I have seen discussions that it does not follow the touchpad standard by Microsoft
• Chrome blocks events from processes that does not run elevated if Chrome is running elevated

There is no method to get rid of Smart Gesture and still have scroll on an ASUS model new, but this gives something that I can work with.

Wow this was posted Oct 2016? I really hope this gets fixed this sooner. I posted a new issue #35844 which was a dupe and go closed. I found when disabling All plug-ins, it was better, but not entirely smooth. But that is also not an optimal solution either. The lag for me is almost 1/2 second on an i7 Surface Book. I tried the code --disable-gpu option and it's also not entirely smooth, but better, so sub par workaround.

Hooking up a mouse proved to be 100% working workaround. Which is kind of ironic.

@Deiru2k Yeah, mouse wheel scroll is fine, but a mouse does not scroll exactly the same as a touchpad. Touchpad has some velocity to it - we all know that from our touchscreen devices. Faster you slide, the fast it should scroll. Mouse wheel scrolls by X rows and is more of a step scroll.

This is still happening for me on my Dell XPS15 with the very latest VSCode (updated today). My work-around is to click win+down-arrow and win+up-arrow. This changes the VS Code window to not be maximized and then back to be maximized. That works, but it's really annoying.

btw, one other piece of info. If I test two finger smooth scrolling in Visual Code 1.17.0 on my desktop which has a Logitech Touchpad, it seems to work ok. Perhaps this is something related to specific touchpad drivers? On the Surface Book it's jerky and unresponsive. But Chrome and Edge are completely smooth. Perhaps it's not entirely related to the app, maybe the drivers, or maybe it's the rate that Electron samples at? I don't really know.

I'm having this issue on a surface pro 4, vscode 1.17.0.
maximise/minimise helps temporarily as mentioned by some others.

The issue is specific to certain devices. My personal machine (an asus rog laptop) behaves exactly as you'd expect two finger scrolling to behave, while my work machine (a dell precision laptop) has the issue reported here.

Also, to reiterate what others from the vscode team have already stated, this seems to be an issue with electron (which I can confirm, as I can reproduce the issue in other electron apps), and is most likely not fixable by the vscode team, unfortunately.

According to this electron issue thread, the issue is with chrome itself.

Here is what I found in chrome's bug tracker: (link)

@EthanRutherford Have you tried the workaround for ASUS mentioned in https://github.com/Microsoft/vscode/issues/13612#issuecomment-324351903 ?

Restarting AsusTPLoader.exe as administrator solves the issue for the ASUS laptops that we have tested on. We even built a node module in our Electron app that does this automatically since we cannot expect our end users to perform that work around.

@EthanRutherford I am not sure this is the same issue as electron/#8960 in the chrome bug report the user says disabling hardware acceleration doesn't fix the problem.

Plus I didn't experience the problem in Chrome.

I actually experienced something similar with Chrome at some point. And at that time the minimize-restore trick helped as well. Maybe Chrome uses Electron as well.

@mogemimi Actually it's the other way around: Electron is based on Chrome.

Also having this issue on Dell XPS 13.

@robinwassen the asus laptop is actually the one which is behaving correctly. The dell trackpad is the one which is having the issue. I usually work with a usb mouse, however, so I don't experience the issue often.

@dopare mentioned that resizing Visual Code corrects the issue. He is right. The issue is likely with the container (electron).

Btw I have the same issue for Chrome itself.
Found possibly related issue https://bugs.chromium.org/p/chromium/issues/detail?id=765311

with the dell xps I have the same issue, resizing helps for a while, and I dont have this problem with chrome, only vscode.

Same problem on Schenker XMG P507 (Win 10, CPU/GPU: i7-7700HQ, Touchpad: Synaptics SMBus). Worse enough to make scrolling with touchpad unusable. No problems in Google Chrome.

same issue on surface book with performance base, my system is below

I have no problem the latest chrome

version 1.17.1
shell 1.7.7
chrome 58.0.3029.110
node 7.9.0
arch ia32

@saedrna I have slow scrolling on Surface Book too, but only when using the internal high resolution screen. Does plugging in an external monitor (a regular one, not 4K) make scrolling faster?

A 40 (yes, forty) line .mustache file makes vscode scroll a laggy mess so suspect this is in electron too.

Having moved from 1.17.2 to 1.18.0-insider scrolling performance is now fixed.

Anyone else want to try the current insider build and report their results?

I just tried it on my Surface Book (the latest preview build of Visual Code) and it's much better. It's not a buttery scroll like one would expect, but it's a lot better than before.

Still broken for me - VSCode Version: Code - Insiders 1.18.0-insider (e6a76e4bd3f52ab07452bb181e861f5a9bfb6596, 2017-10-27T04:19:22.491Z)

(Dell XPS 13 Precision Touchpad)

1. Windows Start Menu -> Code Insiders
2. Code Insiders opens maximized to my previous project
3. Scroll still unusable (it doesn't move during scroll, then suddenly does massive jump after some time)

Good news!

This has been picked up by the Chrome team: https://bugs.chromium.org/p/chromium/issues/detail?id=779372

Great. Vs code is not bad at all, but this issue drove me nuts to the point I completely stopped using it.

@CoenraadS you mentioned before:

If VSCode starts blank and then I open a folder it works ok.

It could be worth filing that as a separate issue from general scrolling performance, as it probably has a different cause.

I had been using VSC in Windows 10 and Ubuntu 17.10 (Gnome 3.26 I think) and was working perfectly, I'm now seeing this issue on Fedora 27 also with Gnome 3.26.2.
I'm running VSCode 1.19
It's happening on other Electron apps too, like Atom.
Resizing the window doesn't do it for me :[

So is everyone here only having issues in VS? I have a Dell Inspiron 7577 Gaming and this scrolling issue is on almost everything. Eclipse and chrome has it the worst. It's also on Discord, Slack, Atom text editor, and source tree. It is driving me so insane I am about to return this laptop.

@RJ-Fynydd I have the same issue in Sublime as well, on a HP Spectre x360. If I remember correctly, I had it in Chrome but "fixed" it by disabling smooth scrolling in chrome://flags/.

This was happening on my Surface Book pretty badly and was very noticeable. Something over the last two releases has improved it (I'm on 1.18), however I still notice that it gets a bit jumpy after usage. In usage, I mean, opening a large code file, scrolling, working on the file, saving, switching to other files, and coming back. A resize of the window seems to still correct it so there is something still wacky with the timing of touch/scroll scan cycles.

Still not smooth on my surface book, I cant believe I stand it for almost one year

@ivyhaswell do you have the latest version of visual code? what happens when you resize the IDE? Does it go away?

If you're using Gnome you can fix this by using Xorg instead of Wayland.
You can change it before log in.
Life is great again.

@alanosman version 1.8.1, the scrolling will come normal for several minutes after resize.

@ivyhaswell so ok - that confirms that we have the same issue on the Surface Book. Hopefully someone here more skilled than me will pick up this issue. :-)

This seems to be happening on Macbook Pro (2015, Retina) as well. It used to work supersmooth, now with a very small project opened, Chrome, Slack and a few others (CPU doesn't get above 1-3%, RAM is 9.4/16GB used) it lags when scrolling.

The issue still persists. I have a Dell XPS 13 2017, win10. Luckily it is fixed resizing the window, as some of you here pointed out. Thanks

I've just come here looking for a solution to this problem.
And I see the issue has been ongoing for over a year.....
I'm using an Asus Strix ROG GL753.

Hu, I thought it would be my mistake but good to see that a workaorund (resizing window) exist. I am using Asus precision trackpad.

Having the same issue (Lenovo Ideapad 720s / 8th gen i7 / 8 gb ram / nvidia geforce mx150)

Same here, very unstable scrolling with my touch pad with Windows Precision Drivers. Sometimes it works, sometimes it does not. VS Code ver: 1.18.1 x64

Getting the same issue while scrolling on my Surface Pro (2017)

This issue still exists in the nightlies. I'm using a first generation Surface Book i7. I'm not sure if this is a timing coincidence, but I only started to notice this issue after upgrading to the Fall Creators Update.

I think this issue is slowly evolving into a feature 😄

Solved in chormium 11h ago: https://chromium-review.googlesource.com/c/chromium/src/+/809829#message-85e8d8e27337bf85caecffcd4978f979a67f1378 .
They are still monitoring, as the buggy code added had to do with the gpu threads.
The electron bug related to this issue : https://github.com/electron/electron/issues/8960

Hope the patch will bubble up soon to vscode :)

Same issue with my skylake XPS13

Same issue. hope it gets fixed soon

It looks like Chrome is testing a fix for this issue (via https://bugs.chromium.org/p/chromium/issues/detail?id=713907#c28) and I produced a VS Code insiders build with that patch backported. I did some testing on my Surface Book where it seems the issue is gone.

If people could give it a try and report back: Download VS Code Insiders 64bit

@bpasero it appears to be working.

@bpasero Fixed here also for XPS 13

@bpasero Working great here. Using Asus ROG Strix. Thanks!

@bpasero Awesome! Thanks!

@bpasero Does this mean we could have the fix applied in daily Insider Builds? Or will it have to wait for the fix to appear in Electron and for VSCode to update to this version?

@warpdesign we can have it earlier in our insider builds because we build Electron for VS Code with our own custom changes if needed.

Massive thanks @bpasero 🙂

Hey, I'm using ASUS R500VD laptop, with Windows 8.1 x64 Pro.

When I start VSCode from git-bash using code ., I cannot use two-finger-tap or two-finger-scrolling in my touchpad. But it works, if I start VSCode from start-menu directly.

23062 was closed as a duplicate but it seems quite distinct, and still unsolved by anything here.

Unless this is not in stable release yet, scrolling is still effed up for me.
Surface book i5 8gb.

@bpasero could you confirm if the fix is in current insider builds or not? I'm using the latest insider, on a Surface Book, and getting bad scroll performance:

Version 1.20.0-insider
Commit 8697a5e4ec152832a2612929c87d56302dbb2e79
Date 2018-01-03T05:14:21.686Z
Shell 1.7.9
Renderer 58.0.3029.110
Node 7.9.0
Architecture x64

The workaround mentioned in #40319 applies here. Resizing the window makes it fast again.

The fix is NOT in stable and NOT in insiders.

Thanks @bpasero. Please give us a shout when it is, I installed the test build above but it got obliterated when an update (which I thought had the fix) came out.

Hi
Also suffering this issue in VSC 1.19.1 on a brand spanking new Dell XPS 15 9560. Dashed annoying it is too.

Resizing the pane works okay, but is too irritating for words. I downloaded the 1.20 build but was unable to open any files ( .ps1, .py, .rb, .go all crash ).

Really hopeful that this fix makes it to stable and GA soon! The main reason I bought this machine was to have a richer VSC experience.

Thanks for all your efforts.

With latest standard build for Windows 10 and a Dell XPS 13, I still have to use "--disable-gpu" argument to get smooth scrolling.

Can't believe it's not solved yet... Suffering this from my Surface book 2

still having to use the workaround for this

@bpasero What's the status on this bug?

bpasero added this to the December 2017/January 2018 milestone on 15 Dec 2017

does it mean it is planned for the next (stable) release?

I thought it was fixed, but was wrong. I tested on Visual Code preview build. It works fine when you open the editor and it's in windowed mode (i.e. smaller than the desktop), but scrolling gets sticky when you go full screen. The issue seems really related to full screen. Also the editor setting editor.smoothScrolling doesn't work (I think it makes it worse when enabled).

Having the same issue on on my Surface Book 2.

A reminder, for those that haven't seen it, the issue is upstream in chromium. From what I can tell, the fix will be in electron 2.0, which has not yet been given a release date. The vscode team have "update to electron 2.0" on the current month's iteration, but of course it can't make it in until the 2.0 actually releases.

Until that point, there really isn't anything vscode team can do about the issue, but rest assured the fix will make it into vscode as soon as it is available.

@EthanRutherford From what @bpasero said, VScode is using its own Electron with some custom changes, so maybe this could be integrated into VSCode without having to wait for Electron 2.0 to be released?

@nico-onmap I'm not 100% sure, but I think he was talking about insiders specifically. Stable probably builds with unmodified electron.

We have a way to backport fixes to our Electron version but I did not have the time to look into this yet. Also, the fix in Chrome is for Chrome Canary (Chrome 66?) and we use Chrome 58...

Having this issue on my Dell XPS 15. Is there ETA on the fix? Or are people moving to Atom already?

This scrolling issue happens on my Lenovo Yoga 920... drives me crazy. Switching to a different IDE
Is there a workaround beside minimizing and maximizing the screen every few minutes??

@navotgil I rather maximize and then minimize, if you consider that as an alternative. Maybe the scroll-ability remains longer in the minimized form, since I do not have to do it for 20-30 minutes sometimes, I guess.

I stretch the minimized form to fit the screen, so I use it like if it was almost maximized. I stretch it from corners to prevent the column snap. I use it minimized, because I have this superstition that the maximized form is more prone to raise the issue.

Open with code --disable-gpu in the terminal. Works for me.

Open with code --disable-gpu in the terminal works for me.

@frenic It really works! Thank you!

Yes, same here; works for me too! Wow, so simple. Why the heck didn't I
think of that ;-)

On 20 February 2018 at 16:04, 张义飞 notifications@github.com wrote:

Open with code --disable-gpu in the terminal works for me.

@frenic https://github.com/frenic It really works! Thank you!

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/vscode/issues/13612#issuecomment-367025826,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AI1HDgJ399foRiWQN2ZViILXKVDSLsx1ks5tWu0BgaJpZM4KU8A9
.

Open with code --disable-gpu in the terminal works for me.

@frenic awesome, thanks.
Does anyone knows the implications it has on performance?

Patch is being backported thanks to chaopeng: https://github.com/electron/libchromiumcontent/pull/453

Don't give up hope

This issue is here ever since vs code came out, and it has rendered vs code unusable in Windows 10. I can understand a small company use electron to target multiple platforms at once, but for a company like MSFT, I really think a more native approach should be considered. Sublime is multi platform, and it's performance/fluidity is even on par with notepad. Microsoft really shouldn't make there fastest growing IDE be depending on Google's product and other companies ability to fix bug for a specific platform.

Xi Editor in the Fuchsia repo is the future of editor. It is still being worked on, but the description is promising. It is multi platform, but it uses each platforms native library to achieve native look and feel and deliver the best performance. It is minimal looking, and will support plugins. I have already jumped ship to sublime due to it's fluidity and smoothness. Xi will be my next choice once it comes out. VS code is cool, but being based on electron makes me never wanna touch it again.

I had purchased this Surface Pro 4 in early 2016. I tried vscode as soon as I've heard about it, but I have been avoiding it for its scrolling issues ever since.

I recently have started using it again after all those years when I have found out that the issue is finally being tracked down and also has some workarounds now. I can only wish that Microsoft's developer tools (VS Community and Code) were as input friendly (touch, trackpad, pen) as, say, Edge or Groove. Then again, only so much can be done with an Electron/Chromium application. My issue is with the very core of vscode.

I think it is fixed in the insiders build

@razielidog Patch was only merged yesterday on Electron 1.7.x: I doubt it is already in the insiders build.

I hope they fix it

this is horrible. touchpad scrolling has an awful lag in vscode. surface pro 5 + typecover.

Yeah @razielidog I think you just moved the window (which is a workaround). It'll slow down again until Electron 1.7 is included as @nico-onmap says.

Been following this for 8 months. I love Microsoft products but Apparently, Microsost own Precision touchpad doesn't work well with Microsoft own product. I know its a Chromium issue but still. Electron is truly pathetic and I have tried countless Electron products not a single one is perfect.

How is this even an issue?

Can people that see this issue give this insiders build a try: Download

It includes a backport of the following Chrome fix to address the issue: https://crrev.com/c/867070

@bpasero No it doesn't solve the problem but one interesting observation. It has no lag on startup but after minimising, it behaves same as insiders build.

@gurpreetshanky can you open devtools (from the help menu) and in the console type "process.versions" and send me the output of doing so?

@bpasero This is the output
Object {http_parser: "2.7.0", node: "7.9.0", v8: "5.8.283.38", uv: "1.11.0", zlib: "1.2.11"…}

@gurpreetshanky I meant to say, type this: process.versions["atom-shell"]

@bpasero "1.7.12"

@gurpreetshanky too bad, let's see if others report something else. I will double check that the backport was included in the build... (the version 1.7.12 is correct at least).

@bpasero Yes but definitely an improvement on startup. Also, When will vs code will be updated to electron 2.0. In Atom touchpad works fine. Why is this only affecting vs code?

@bpasero I tried the build on my Surface Book and am having the same behavior than @gurpreetshanky: works and breaks again after window is minimized/restored.

Did someone test Chrome builds with the fix: maybe it is not fixed correctly? It's been buggy for years, I wouldn't be surprise :/

Correction: I misunderstood the term minimize as getting out of the maximize. Minimizing to the taskbar brings the issue back here also.

@bpasero I also just tried it on my Surface Pro from the link in comment, and didn't have the issue anymore. I tried minimizing/restoring to get it back, but couldn't. Minimizing/restoring was the workaround I was doing to temporarily fix the issue on the release build, so I don't understand how it this time would not fix but bring the issue back, really...

Even a single verification that issue persists should be enough to say that it's not truly fixed, however, and we have two. I probably am just not triggering it somehow.

@bpasero i have to agree with ThoAppelsin, it seems to be fixed in this build.
Tried to reproduce and couldn't

@bpasero Yes but definitely an improvement on startup. Also, When will vs code will be updated to electron 2.0. In Atom touchpad works fine. Why is this only affecting vs code?

We are looking into updating to Electron 2.0.0, but it will probably take more time. If you want to check if the issue reproduces in 2.0, you could try with this test build (link), however it does not include the fix yet.

I cannot explain why it does not reproduce in Atom...

Did someone test Chrome builds with the fix: maybe it is not fixed correctly? It's been buggy for years, I wouldn't be surprise :/

I can do that next week, we have a reproducible case with Chrome as well. If you run chrome from the command line pointing it to some website that scrolls, we could make the lag appear directly. The key seems to be to not type the URL into a tab, but let Chrome start with a URL directly.

@bpasero I also just tried it on my Surface Pro from the link in comment, and didn't have the issue anymore. I tried minimizing/restoring to get it back, but couldn't. Minimizing/restoring was the workaround I was doing to temporarily fix the issue on the release build, so I don't understand how it this time would not fix but bring the issue back, really...

@ThoAppelsin are you saying that this issue is fixed for you even when you minimize/restore the window?

@bpasero i have to agree with ThoAppelsin, it seems to be fixed in this build.
Tried to reproduce and couldn't

@razielidog and it remains fixed even when you minimize and restore the window?

Same as gurpreetshanky. No lag at startup but min/max brings it back.

@bpasero My bad. I misunderstood the terminology, and probably confused @razielidog as well. There actually are these three terms, Maximize/Restore/Minimize, and I misunderstood minimizing as getting out of the maximize, and that does not bring the issue back.

Minimizing the window to the taskbar and restoring it back, does bring the issue also back.

@bpasero Is the bug fix included in public Chrome releases? Chrome Version 65.0.3325.146 (Build officiel) (64 bits) exhibits the problem when started from the command line with a website as parameter (and is gone when a new tab is opened, but I think this was known).

Edit The problem is fixed in Canary builds (Version 67.0.3367.0 (Build officiel) canary (64 bits)), and definitely fixed: minimizing/restoring doesn't bring back the problem. So it hasn't made it into stable yet.

@ThoAppelsin at least we have all the same behavior.

@warpdesign I believe it is only in Chrome 66, can you try with their beta release to see the behaviour? Thanks for giving this a try 👍

@bpasero tried both Chrome Beta & Canary, here are the results:

• Beta (65.0.3325.125): bug is there, same behavior as VSCode stable (scrolling lags, minimizing/restoring temporarily fixes it)
  
  
  
  • Canary (67.0.3367.0): bug is definitely fixed: minimizing/restoring doesn't bring it back
  
  

So it seems like the patch you applied kinda reversed the problem, ie: it's fixed by default, and restore/minimize brings it back.

I can confirm Atom (1.24.1) doesn't exhibit the problem which is using Electron 1.6.16.

How about cooperating with Atom since they don't have the problem? Did they have it? If so, how did they fix it? If not, why not?

@warpdesign you would have to test with Atom Beta (1.25.x with Electron 1.7.11) though to match the same Chrome version that we are using. It is possible that Electron 1.6.x does not have this issue after all because it uses an older Chrome version.

I am trying to follow up with Electron if their backport is maybe not complete (discussion in https://github.com/electron/libchromiumcontent/pull/472).

Thank you for the work on this!

@bpasero I just tried with Atom Beta (1.25.0-beta3, Electron 1.7.11) and scrolling works perfectly: no lags, no problem when minimizing/restoring.

@warpdesign hmm So bug is in vscode code base?

@gurpreetshanky you cannot really say that because this bug reproduces in Chrome and was confirmed to be an issue with Chrome and fixed by them meanwhile. It is unclear to me how Atom does not trigger the issue though and unclear why the fix works in Chrome but not for us after minimize/restore.

@bpasero maybe the bug fix relies on some other fixes/changes which were not applied? How about getting in touch with the person who submitted the Chrome patches for this bug?

@warpdesign to be fair, this patch was applied on top of Chrome 66 and we are putting it on top of Chrome 58, so it could well be that something else is missing...

Can people that see this in stable confirm that the issue is coming back once you minimize and restore? I am trying to understand if we always had that issue with minimizing/restoring brings the issue back.

My testing with Surfacebook seems to indicate that this issue existed before. Which means the backport fixes it on startup but is not worse than before with regards to the issue coming back on minimize/restore.

Yes it exists in the current stable build (minimizing+restoring makes scrolling laggy):

Version 1.21.0
Commit 9a199d77c82fcb82f39c68bb33c614af01c111ba
Date 2018-03-07T11:04:09.969Z
Shell 1.7.9
Renderer 58.0.3029.110
Node 7.9.0
Architecture x64

(at least on my Dell XPS 15 9560)

In my opinion even this partial fix would be good to be merged in insiders until the minimize bug is sorted. From a usability point of view at least.

@ynotzort does it also come back with other gestures on the Window? Like switching between application windows? I am asking because minimize/restore seems like a less frequently executed task compared to switching Windows.

@bpasero does not seem like it, at least alt+tab and windows+tab does not make the issue appear for me.
However using windows+d (minimize/restore all windows) makes it appear, which is quite annoying...

Just chipping in that I get this issue on latest Version 1.21.0 even before minimize/restore. If I open a file in VS Code, scrolling is choppy with touchpad. I have set:
"window.menuBarVisibility": "toggle"
So my quick workaround for it is to press ALT, which makes menuBar appear and issue disappears. That is until minimize/restore cycle when it comes back.

@marchom Thanks for the tip, I much prefer that to resizing as a workaround.

Seems like bug behaviour follows this pattern on 1.21.0 (Windows):

• Appears
  
  
  
  • on startup
  
  
  • after minimize/restore when maximised (either with buttons or Win + D)
  
  
• Disappears
  
  
  
  • when starting vscode with --disable-gpu flag
  
  
  • on resize
  
  
  • while holding CTRL or ALT
  
  
  • after tapping ALT (Only if you have the menu bar hidden)
  
  
  • after toggling full screen mode (F11)
  
  
  • if developer tools are open Help -> Toggle Developer Tools
  
  
• No Effect
  
  
  
  • after minimize/restore when vscode is focussed, but not maximised
  
  
  • ALT + TAB
  
  
  • Win + TAB
  
  

Double tapping F11 (Fullscreen toggle) also removes the issue for me. Running code --disable-gpu works as well...

Whats weird is that if VSCode is not in maximized, then minimizing and restoring does not trigger the issue for me...

I had the problem with Discord that is also using Electron.
(I can't relate more because I'm working 80% of my time on Linux)

Whats weird is that if VSCode is not in maximized, then minimizing and restoring does not trigger the issue for me...

@ynotzort Can confirm this behaviour. Updated my list

I use maximize/restore or restore/maximize as my workaround, and it works (as far as I recall) all the time. Perhaps this workaround could be issued programmatically whenever vscode is brought up from taskbar after being minimized?

I am not informed enough on these subjects, but maybe it can be done atomically enough, without the window being re-drawn at all. Until the fix comes and propagates all the way from the chromium/electron to vscode, vscode could have it patched like this as a temporary measure.

@pd93 I also noticed that Help -> Toggle Developer Tools also mitigates the issue. For some reasons if developer tools are visible lags never occures.

@karasq Thanks, I can confirm this. I can only assume that having the dev tools open is causing a resize when you focus vscode? Though I have nothing to back up this theory.
I have added it to my list ^^^

@karasq thank you, Help -> Toggle Developer Tools worked for me,
and code --disable-gpu worked as well

@bpasero i just saw that in the release notes of electron 1.7.13 "Fixed support for precision trackpad / mouse scrolling." is highlighted. Maybe this version could be used instead of 1.7.12?

@razielidog we use 1.7.12 but with that exact patch backported...

With todays insider build (3a70cdfd8f84136e858b3d39e5a709e637fc35e7) you can set "window.smoothScrollingWorkaround": true to get back smooth scrolling when restoring the Window. This build also includes an Electron version that will fix this issue on the initial startup.

Let us know how it goes. The reason why this new setting is not enabled by default is a) it is just a workaround and not the real fix yet b) it results in some flickering of the Window when you restore it.

@bpesaro great news! I don't have access to my surface book right now, will try it in a few days. Does the flicker mean the patch is reapplied each time the window is restored?

@warpdesign the flicker is literally coming from the fact that with that option enabled I toggle the menu bar visibility when the window gets restored. This will not happen on the initial startup though.

@bpasero Workaround works as expected on my Surface Book, no more lag after minimize/restore.

It seems that the issue has something to do with windows version (especially precision touchpad) . If run VS code in the compatible mode of windows 7, scroll lag disappears and will no longer appear again.

@TXH1997 Thanks for the compatibility mode idea. Windows 7 comp.mode seems to permanently fix my scroll lag issues (on surface pro 4).

@TXH1997 because running it in a compatibility mode means running without GPU. So functions like integrated terminal won't work.

Yup, it's just a temporary solution. Bug remains to be fixed...

hoping to get this fixed from a long time, don't understand why MS is not being able to give a proper fix.

Seeing this currently on a Surface Book on version 1.21.1

I will lock this issue so that people can see the current workaround that we ship with 1.22:

I am unlocking this issue to get some feedback around the fact that Windows 10 has been working on a fix and it seems to be included in Windows 10 Insider Preview Build 17751 and will be included in the October update (RS5).

If anyone could verify the issue is indeed fixed with that Windows 10 insiders build that would be great. So far I heard from @Drae in https://github.com/Microsoft/vscode/issues/53793#issuecomment-417922382 that the issue was resolved.

To verify:

• update to Windows 10 Insider Preview Build 17751
• remove the setting window.smoothScrollingWorkaround (if configured)

@bpasero No problems anymore with 17751 on a Surface Book.

@bpasero Yes the problem is solved with 17751.1 on Dell XPS 15 with precision touchpad.

Out of curiosity: did anyone ever hit this issue on Windows 7 or Windows 8? I am asking because the fix will probably only ever be made on Windows 10.

@bpasero I don't think it would happen on earlier versions of windows because they didn't support precision touchpads, if I remember well.

Will this change be present in the Windows 10 October 2018 Update when it is released?

My hp desktop pc power is on for one minute but monitors are not open and mouse or keyboard has been not working when updated my windows 10 before two years ago

@bdr99 yes it will be available as part of the October update.

Closing this as the Windows 10 October update is rolling out to people. This bug is fixed as part of the Windows 10 RS5 update.

Awesome, now have to wait for RS5 - hopefully tomorrow.

We decided to keep the "window.smoothScrollingWorkaround": true for this release and we plan to remove it in the future when more users update to the latest Windows.
Can somebody who does not have the latest Windows 10 version please take this insider build and verify that the window.smoothScrollingWorkaround works as before and that scrolling is smooth? I would really appreciate it.

https://az764295.vo.msecnd.net/insider/1d0e4299c6ccfe9210252c811b4247cfdc8a6a44/VSCodeSetup-ia32-1.29.0-insider.exe
https://az764295.vo.msecnd.net/insider/340133accd0b66202bde342f995f00b02f63c0d4/VSCodeSetup-x64-1.30.0-insider.exe

@isidorn I don't have the October update installed yet, so I installed the insider build to test.

But thing is, the KB4462933 update fixed the issue for me. Now there's no difference between stable/insider builds, and with/without window.smoothScrollingWorkaround after the update.

Here are more testimonials: https://github.com/Microsoft/vscode/issues/62327#issuecomment-436597428, https://github.com/Microsoft/vscode/issues/61824#issuecomment-433785824.

@HazemAM thanks for jumping it!
That is why I need somebody who does not have the latest windows update to try it out so we can verify that the setting still works.

@isidorn Oh, so you meant the latest incremental update, not the October update?

Yeah I guess I need someone that does not have https://support.microsoft.com/en-us/help/4462933/windows-10-update-kb4462933

Keep in mind that it is not enough to just configure window.smoothScrollingWorkaround: true, you will also have to disable the custom title via window.titleBarStyle: native.

I have no available windows updates to install (I am up to date), latest vscode and I am running bootcamp windows.

When using the trackpad, there is absolutely no way (with any of the combination of suggestions in this thread) to get smooth scrolling working. Vscode ignores my control panel mouse wheel settings. The only way I can get vscode to behave is by setting the "editor.mouseWheelScrollSensitivity": 0.2 however I switch between using a trackpad and a mouse, so I have to change this setting every time I switch device!

At the minute vscode is pretty unbearable to use because of this!