Unable to reproduce the issue on Windows 10 with chrome #58.0.3029.81
Didn't observe any unresponsiveness while scrolling the test webpage "https://www.awwwards.com/sites/metalloinvest-10-years"

austinthibodeaux@ Could you please let us know the url on which you have faced this issue for further triage.

 

I'm also experiencing this, especially in Electron apps. Not sure if there is a dedicated issue for this already, but a lot of people have this issue, see:

https://github.com/Microsoft/vscode/issues/14716
https://github.com/Microsoft/vscode/issues/13612
https://github.com/electron/electron/issues/8960

It is fixed with a workaround, by doing Win+Down + Win+Up.

This issue was first reported to VS Code when we updated to an Electron version using Chromium 52. We are now on Chromium 56 and the issue is still reproducible when opening a VS Code window in a maximized state. A single resize of the window will permanently make scrolling with the trackpad be smooth again for the duration of the window lifecycle.

Does that ring any bells for you, did you have any such issue with Chrome?

If not, we might need to ask our Electron friends of what starting in a maximized window could have to do with precision touchpad scrolling.

P.S. Thank you for your great work! 

@alex

I can't confirm. Google Chrome still lags when scrolling even when unmaximized and and when I have resized the window. However, the lag improves when I resize the window to a small fraction of the screen (1/4 or 1/6 of the screen).

Thank you for providing more feedback. Adding requester "kkaluri@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

I'm having this issue aswell in the latest version of VS Code, using an Asus UX360C with precision touchpad and Windows 10 x64. 
In my case, the behaviour is the same as described by @alex. When I scroll with the touchpad, it has a 1 second delay (aprox), then jumps to the scroll position; this happens each time I release the touchpad and scroll again.
If I resize or maximize/minimize the window, it gets fixed until the next launch. This happens wheter the program starts maximized or minimized.
Scrolling by other means, like dragging the scrollbar or using the touch screen, always behave correctly.

Thank you!

austinthibodeaux@ could you please help us with sample html which uses the VS code for our further triage.

I'm having the same issue with vs code using just about any project for a while on a surface book with it's precision touch pad. A workaround is to resize the window. This issue doesn't happen using an external mouse. I have the exact same issue using the chrome debug tools on Chrome 62 as well.

Actually the issue happens when using a high precision track pad with the very first tab opened in a chrome process, and only as long as you don't resize the window.
In other words, when the chrome process is closed and then you open as the very first (and only) tab a scrollable page. Resizing the window fixed it.

For example, just close the chrome process and then on a command line do "start https://github.com/electron/electron/issues/8960#issuecomment-288228600". or whichever url that contains an scrollable page. 

I can reproduce the behaviour reported in https://bugs.chromium.org/p/chromium/issues/detail?id=713907#c10.

The crazy thing is that the scrolling becomes smooth as soon as I open another tab or resize the window. The same issue fixes itself in VS Code when resizing the window.

Any idea what kind of code could get executed that helps for smooth scrolling when opening a new tab or resizing the window?

I can confirm the same behavior as comment 10 on a dell xps 13. Easiest way to re-create is to just right click any link | open in new window, and try scrolling in the new window.

I had entered an issue here before I came across this comment: https://bugs.chromium.org/p/chromium/issues/detail?id=778454

I have the same problem, on Lenovo X1 Carbon Gen 5.
I can confirm, that the easies way to recreate is to follow guide in comment 12
All electron apps are also affected by this issue. I am also struggling with VS Code

Both TouchPad and TrackPoint scrolling is not smooth, even if you use it slowly.

Win 10 x64 1709 (OS Build 16299.19)
Synaptics Pointing Device
Driver Data 12.10.2017
Driver Version 19.3.4.111
Hardware Ids ACPI\VEN_LEN&DEV_0072
Compatible Ids *PNP0F13
Device Instance Path ACPI\LEN0072\4&770362D&0


Thanks!

Another way to reproduce is to go to chrome://flags, change a setting which prompts 'relaunch now'. Click relaunch, scroll is now broken until window is resized.

I can provide a trace if someone can tell me how to trace when opening a page in a new window. Currently if I open a new window while tracing I get an 'Aw Snap' message.

I managed to repro on a surface book pro - it's tough to trace since opening a new tab to trace makes the bug go away. I got a trace by launching Chrome from the command line: 

chrome.exe --trace-startup --trace-startup-file=C:\tmp\trace2.json --trace-startup-duration=15 --categories=* http://reddit.com

Note, you'll have to unzip it to load it into chrome://tracing

Deleted: trace.zip 8.7 MB

trace.zip 8.7 MB Download

 Issue 778454  has been merged into this issue.

located this issue introduce between 384715 and 384749.

https://chromium.googlesource.com/chromium/src/+log/7f8f2c5601e8506e62615e48e4a83424ea4b1c0b..531e24dbc6d660b82a216f5ef81fa06661434485?pretty=fuller&n=10000

the per-version range in #20 is wrong, should be 384695 - 384715
a57621dbfacb introduce this issue.

I just want to clear things up a little bit. Some people may be confused for which operating system I am having issues on since I failed to include the OS version.

I am running Windows 10, however I have tested this issue on the Linux desktop as well, and I have come to the conclusion that the Linux version of Google Chrome has more responsive scrolling on Linux than Windows 10 on the same laptop.

The laptop that I am currently using, the Lenovo Yoga 710, is notorious for having poor Linux support and has god awful compatibility with Linux with the touchpad and touchscreen drivers. However, I have managed to get things to (sort of) work by updating to the newest non-LTS versions of Ubuntu. Granted, the high resolution display can bog down the system in terms of framerates when scrolling, especially with the notoriously bad Nvidia graphics drivers, but overall the scrolling is much more responsive on Linux than it is on Windows 10.

From my experience, this appears to be a Windows 10 performance issue which probably has to do with the high resolution display. On this laptop, I kind of expect some framerate issues while scrolling in high resolution, but I do not expect the responsiveness to go down the toilet. However, this doesn't mean the framerate issues shouldn't get any attention, because Microsoft Edge manages to stay at 60 fps in most cases.

+stanisc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/12dca8659ca7a447e813d0d25f930cf7932b87fd

commit 12dca8659ca7a447e813d0d25f930cf7932b87fd
Author: chaopeng <chaopeng@chromium.org>
Date: Wed Dec 13 04:32:17 2017

Fix Windows touchpad lagging in first tab

Currently the receiving of WM_MOUSEWHEEL messages lags when we open a
URL on a new window until we resize. The issue was introduced by
r384698. That CL change wait for MOUSE_EVENT to wait for SENDMESSAGE
in MessagePumpForUI::WaitForWork to optimize the GPU thread. But the
GPU thread does not use MessagePumpForUI anymore so it should be OK to
just remove that code.

The updated version of Chrome was tested to make sure that the hangs
that were occasionally seen when using chrome://tracing are still gone.

After this CL chaopeng@ need to monitor to make sure that the crash
rate not increase.

Bug:  713907 , 596190
Change-Id: I7545a867de4851acd4e57c9b8c7a3dd05def1dd8
Reviewed-on: https://chromium-review.googlesource.com/809829
Commit-Queue: Jianpeng Chao <chaopeng@chromium.org>
Reviewed-by: Bruce Dawson <brucedawson@chromium.org>
Reviewed-by: Lei Zhang <thestig@chromium.org>
Cr-Commit-Position: refs/heads/master@{#523689}
[modify] https://crrev.com/12dca8659ca7a447e813d0d25f930cf7932b87fd/base/message_loop/message_pump_win.cc

Is it safe to apply (backport) this patch on top of Chrome 58? I would like to test this out in VS Code where we still are on an older Chrome version.

Hi benjamin, we are monitoring the fix, but feel free to try on m58 (may need a simple  merge) for vscode. 

There shouldn't be any issues backporting it.

Awesome, I am already on it :)

My initial testing on VSCode with this fix backported (Chrome 58) looks promising. I am not seeing the bad lag behaviour as before. I am still waiting on some more verification by other users, but so far it seems to be a good fix.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/ffe75f56318e0e3c2f29ee0a1156c85f83dfad2e

commit ffe75f56318e0e3c2f29ee0a1156c85f83dfad2e
Author: Jianpeng Chao <chaopeng@chromium.org>
Date: Fri Dec 15 19:22:35 2017

Revert "Fix Windows touchpad lagging in first tab"

This reverts commit 12dca8659ca7a447e813d0d25f930cf7932b87fd.

Reason for revert:  crbug.com/795223 

Original change's description:
> Fix Windows touchpad lagging in first tab
>
> Currently the receiving of WM_MOUSEWHEEL messages lags when we open a
> URL on a new window until we resize. The issue was introduced by
> r384698. That CL change wait for MOUSE_EVENT to wait for SENDMESSAGE
> in MessagePumpForUI::WaitForWork to optimize the GPU thread. But the
> GPU thread does not use MessagePumpForUI anymore so it should be OK to
> just remove that code.
>
> The updated version of Chrome was tested to make sure that the hangs
> that were occasionally seen when using chrome://tracing are still gone.
>
> After this CL chaopeng@ need to monitor to make sure that the crash
> rate not increase.
>
> Bug:  713907 , 596190
> Change-Id: I7545a867de4851acd4e57c9b8c7a3dd05def1dd8
> Reviewed-on: https://chromium-review.googlesource.com/809829
> Commit-Queue: Jianpeng Chao <chaopeng@chromium.org>
> Reviewed-by: Bruce Dawson <brucedawson@chromium.org>
> Reviewed-by: Lei Zhang <thestig@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#523689}

TBR=thestig@chromium.org,brucedawson@chromium.org,chaopeng@chromium.org

# Not skipping CQ checks because original CL landed > 1 day ago.

Bug:  713907 , 596190,  795223 
Change-Id: I3f53fd77e7a6545cd214444cac46709cff0142c9
Reviewed-on: https://chromium-review.googlesource.com/830174
Commit-Queue: Jianpeng Chao <chaopeng@chromium.org>
Reviewed-by: Jianpeng Chao <chaopeng@chromium.org>
Cr-Commit-Position: refs/heads/master@{#524428}
[modify] https://crrev.com/ffe75f56318e0e3c2f29ee0a1156c85f83dfad2e/base/message_loop/message_pump_win.cc

That is too bad, is there an alternate fix possible?

Hi Benjamin, I am trying to alternate fix. I have talk about  crbug.com/795223  with rebornix@, You can that until we have a new fix since 795223 only effect print page and vscode does not have print page. 

So you are saying the regression of the fix does not have any impact unless printing? 

Anyway, thanks for looking into another fix :)

Any update to this issue or my question?

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/f77fb4f7114017bd995d081a424b52e3d7d437d7

commit f77fb4f7114017bd995d081a424b52e3d7d437d7
Author: chaopeng <chaopeng@chromium.org>
Date: Fri Jan 19 20:31:42 2018

Correct the z-order of Intermediate D3D Window after reparent

The scroll lagging issue and DM_POINTERHITTEST missing issue are caused by
"Intermediate D3D Window" being in front of "Chrome_RenderWidgetHostHWND"
when Chrome starts until a manual resize calls SetWindowPos and moves
"Chrome_RenderWidgetHostHWND" to the top.

In this patch, we move the "Intermediate D3D Window" to the bottom after it
reparents to root window.

Bug:  713907 ,  793036 
Cq-Include-Trybots: master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
Change-Id: I9d847f5cfb57819ad1a7dfd54aa62932e2eca8c0
Reviewed-on: https://chromium-review.googlesource.com/867070
Reviewed-by: Antoine Labour <piman@chromium.org>
Reviewed-by: Scott Violet <sky@chromium.org>
Reviewed-by: Bruce Dawson <brucedawson@chromium.org>
Commit-Queue: Jianpeng Chao <chaopeng@chromium.org>
Cr-Commit-Position: refs/heads/master@{#530601}
[modify] https://crrev.com/f77fb4f7114017bd995d081a424b52e3d7d437d7/gpu/ipc/in_process_command_buffer.cc
[modify] https://crrev.com/f77fb4f7114017bd995d081a424b52e3d7d437d7/ui/gfx/win/rendering_window_manager.cc

chaopeng: do you think that this is this a fix that I could apply onto Chrome 58 as well?

Hi Benjamin, sure but rendering_window_manager has rename so many time, you may need some time to figure out. I suspect you should change here: https://github.com/electron/electron/blob/master/atom/browser/native_window_views.cc#L985-L992

Thanks, yeah I will try to apply the patch. I was more wondering if you consider this fix to be stable enough to be merged on top of Chrome 58. I will give it a try!

No Regression for 1 week.

It looks like the patch requires changes from another one which only landed in Chrome 65: https://bugs.chromium.org/p/chromium/issues/detail?id=787099

That is unfortunate and will make it hard to backport onto Chrome 58 I fear...

Is this issue only supposed to cover Precision Touchpad, or does the same code handle touchscreen?  I have a Surface Book 2, which is equipped with both.  I had the PTP issue (especially in VS Code) for a long time, but that seems to be resolved recently.

The weird thing is, now I'm noticing it in Chrome 67, but only with the touch*screen*, not the pad.  I can scroll any page completely smoothly using the pad, but if I try to drag the screen with a single finger, I get the "bad" behavior I used to see with two fingers on the pad -- scroll stutters and stalls out, appearing to freeze until I release my finger.  Even stranger, making the page full-screen (F11) and back again fixes the issue, just like the workaround I used to use in VS Code.  Happens on any page that scrolls, including this one.

Should I report a new bug or re-open this one?  Win10 17134.112, Chrome 67.0.3396.87.

Hi James, I am not able to reproduce your lagging issue in 67/68/69. Also this fix should not effect touch screen. Please open another issue.