Re-think isScrolling param and debounce behavior

[bvaughn]

The isScrolling parameter can be used to render a light-weight representation of a cell while the user is scrolling to avoid eg doing too much paint and layout work, making unnecessary network requests, etc.

Trouble is, the value of isScrolling is one of the factors used to determine whether cellCache is used or not - meaning that, if it's not used, this parameter can have a net negative impact on performance.

This behavior can be worked around currently by setting the value of scrollingResetTimeInterval to 0 to disable the debounce behavior. Perhaps the API should change to make isScrolling something that is opt-in instead of opt-out?

[MrNice]

I can say that I tried to use isScrolling and it significantly degraded performance (when tested on
a macbook pro retina). It seemed like it caused more work to happen in one chunk once scrolling stopped. Sorry if this is unhelpful.

[bvaughn]

No worries. Feedback is helpful. That's why I tagged this issue "discussion".

It seemed like it caused more work to happen in one chunk once scrolling stopped.

It would require one final render after scrolling stops (to switch from isScrolling true -> false). This may or may not be net positive, depending on what your app is doing.

[djeeg]

This is definitely an interesting point.

I spent a fair bit of time going down the isScrolling path, trying to improve the perf of the scrolling Grid. Did do a fair bit of debugging however couldnt really get the performance close to what I wanted.
#728
#717

The demo page works really well (probably because its a very simple box to render). As soon as you start throwing a more complex cell at the scroll, the render performance takes a hit.

I currently have that special render logic for isScrolling disabled and am more reliant upon CellMeasurerCache to provide a smooth scrolling experience. Specifically I can luckly use both fixedWidth=true and fixedHeight=true.