Improved render performance while scrolling in Chrome under weird condition

First of all, thanks for all your contributions to the community and in particular this amazing library. Second, I want to apologise in advance if this has already been noted elsewhere and I have missed it.

While creating some debug overlays to visualise the rendered item regions, I stumbled on a weird situation in Chrome (Version 80.0.3987.163) on macOS Catalina where I see improved performance if I cover the scroll region with an absolute-positioned element with pointerEvents: "none" styling:

Here is a codesandbox.io link that demonstrates the situation - because react-window is so performant already, I find it’s best to break the preview off into its own window and scroll vigorously (really get those fingers flyin’) to see the flashes of empty content. Then tick on the “show overlay” checkbox at the bottom of the page and observe the difference. It’s odd, but no matter how hard I try I can’t get the flash to occur while the overlay is visible.

I’m curious if someone can enlighten me as to what might be happening here? I’ve probably neglected to think of something obvious. Are there any drawbacks you can think of if I just…keep this overlay there all the time? Thanks for your thoughts!

[JavanPoirier]

Thanks @beauroberts. This was occurring only on Chrome on Mac, where list items would not show when swiping/scrolling fast and I was definitely lost as to why. Having tested a few different list library examples, this only occurred with react-virtualized and react-window out of those I tested.

[beauroberts]

Hey @olehhusiev thanks for confirming that it works for you too! I have a test environment with 10,000 items and it seems to be performing nicely also.

By “heavier-weight cell” I mean a cell that takes more time to render than the simple text cell I used in my example. When this hack is in place, you can get poor scrolling performance if the individual items are very costly. But if you have optimised the rendering of your items, it seems like this hack can lead to better perceived performance.

My colleague @woollenhat did more thorough investigation into this than I did, and discovered a couple of interesting things:

First, that the performance is actually better without the hack, as demonstrated by the two halves of the profiler output here. The left half is without the overlay hack and the right half is with the overlay hack:

Second, he noticed that when you place the overlay over only half of the scroll container, the performance changes based on where your mouse is. That effect can be seen in this forked sandbox - scroll with the trackpad rapidly on the overlay half and you have different behaviour than when you scroll on the non-overlay half. So it is related to the element the mouse is over at the time of scrolling, maybe?

He realised that scrolling over the overlay seems to enable a different scroll mode, as can be seen in the call trees here:

Note that one is gesturescrollupdate and the other is just scroll.

He also pointed me to this article about changes to the scrolling implementation in Chrome, moving it off of the main thread.