Bug: performance deteriorates when using ReactDOM.createRoot instead of ReactDom.render for virtual-table. about react

[sophiebits]

I can reproduce that when dragging the scrollbar in your simplified codesandboxes, there is more visual lag for the boxes to appear in the createRoot version, like in your video.

In the createRoot version, I tried replacing the forceRender call with

flushSync(() => {  // imported from react-dom
  forceRender({});
});

which forces React to perform that one update synchronously and that seems to make it behave similarly to the ReactDOM.render call, which you may be able to use as a workaround. (For example, you can use flushSync even once ReactDOM.render is removed – although it may not be fully compatible with new features like the use() Hook.) Note that the state update is performed immediately and cannot be batched with any state updates enqueued after the flushSync call, so in your current setup you need to edit the ref beforehand, and you need to be careful that you don't have other scroll event handlers that might rerender the same grid (or measure layout in an effect) to avoid possible performance issues.

Internally in React, when you trigger an update within a scroll event, the update is assigned the ContinuousEventPriority level, which is mapped to UserBlockingPriority in our scheduler. Unlike some other event types like click, React does not force this to flush immediately, the idea being that continuing to respond to other user interaction (if any occurs) is more important than rerendering based on a scroll event. So React may return control to the browser (vs for a click event it will finish rerendering even if it means causing the page to freeze for a sec). However in my testing the rerender is not coming close to hitting the deadline; I tried adding an effect to Grid that logs the current time for every render and generally one happens every 16ms.

@acdlite Do you have any other insight to share on why this lags or what to do? (Is there a supported way to opt into DiscreteEventPriority from a scroll event?)

[timwiegand]

I have the same problem. I used the Chrome performance profiler on my own simple sample and zoomed in on a single frame. The results confirm the theory that React is returning control to the browser after SetState is called. The browser paints before the render is scheduled. The end result is that while scrolling, the browser paints using the DOM rendered for the previous frame. When using react-window, the control goes blank when you scroll fast because each frame you've scrolled past all the content react-window rendered for the previous frame.

The entire sequence shown here takes less than 5ms. The rest of the frame is idle. I think the browser is coalescing input events until just before the paint is due, then raising the scroll event. At this point anything scheduled for a callback will run after the paint. It doesn't matter how quick the render is, because it doesn't start until after the paint has happened. The same thing will happen for updates triggered using requestAnimationFrame.

Would it be possible to start processing UserBlockingPriority tasks before returning control to the event loop, while still allowing them to be interrupted if it takes more than 5ms? This is in keeping with the philosophy of not blocking renders while allowing fast updates to complete before the browser paints.