Vertical scrolling is not smooth, scrolling lags mouse movement

Tags: #<Tag:0x00007efc64de4128> #<Tag:0x00007efc64debf90>
#1

Hi, just coming back to a prototype I built last fall. Trying it with current data, the vertical scrolling is not smooth like that of the horizontal scroll bar but very delayed where it is a couple of seconds before it even tries to move.

Is there any way to prevent this or make it scroll more smoothly?

#2

Hello @matt1,

Make sure that you’re not overloading the grid with operations that cause excessive rendering. You can use methods like batch to perform multiple operations without re-rendering the grid after each one.

Check your Handsontable configuration for scroll settings. You might need to adjust properties like scrollV or stretchH to improve the scrolling behavior.

Handsontable provides a guide with performance tips that can help you optimize your grid. This includes advice on how to handle large datasets and improve the overall responsiveness of the grid.

If you haven’t updated Handsontable since last fall, consider upgrading to the latest version. New releases often include performance improvements and bug fixes.

Sometimes, the issue might not be with Handsontable itself but with other scripts or styles on the page that interfere with the grid’s performance. Inspect your page for any such conflicts.

Best Regards,

#3

Hi @matt1

That might be related to a heavy use of custom renderers or logic applied to scroll events. Can you share more details about the implementation?

#4

Hi Betty, I just tried searching for scrollV and could not find it. I am using the current version.

#5

Hi Aleksandra,

There is quite a bit of data and formatting. I do have a nasty little afterChange hook but I have not updated anything. Scrolling becomes worse as depending on the number of rows. I commented out the afterChange and that didn’t make much of a difference.

Is there a way bypassing the viewport swapping of rows to allow allow the rows to be constructed? With that I think this problem would go away.

#6

Hi Aleksandra,

I stumbled across the renderAllRows option. That works in answering my question regarding the viewport swapping of rows.

However, it now takes about 35 seconds for the actual page rendering which not ideal. The page with data imbedded is about 2.6MB.

Any suggestions or ideas on how optimize the loading process?

#7

Yes, the renderAllRows option is pretty heavy for the loading time, but then the table doesn’t need to reload when you scroll it vertically.

There’s an option between those two (do nothing or use renderAllRows) - you can set up the viewportRowRenderingOffset. Reference: https://handsontable.com/docs/javascript-data-grid/api/options/#viewportrowrenderingoffset

Each project is different, so I cannot define which value would be the best in your case, but if you set it up to countRows() - 1, you will get the same effect as with the renderAllRows.

If you haven’t seen those tutorials I highly recommend checking

#8

Hi Aleksandra,

Thanks for the tips. I will definitely look at these.

A couple of observations on the rendering process (please bear in mind that this is being done on a high end machine on an i9-14900 K with 64GB of memory and high end video card, so these numbers are way beyond the numbers that would probably be seen on a typical user machine).

When default render mode is used I see three timings for the rendering (initial start of timing is using beforeLoadData):

966ms
3867ms
5498ms

If renderAllRows is set to true, the timings are:

2983ms
16505ms
30130ms

In both cases the timing is cumulative to that point when the hook was called.

When updating a cell, the time is

13676ms
27502ms
41356ms

So, it is really slow in handling things (and yes, I do understand the calc engine underneath the covers has a lot of stuff it must worry about as well).

The size of the page grid is approximately 300+ rows x 400 columns just for context.

#9

With fluctuations like that it has to be one of the following

  • Extensive use of cell renderers and styling
  • Heavy formulas, for example when one cell changes 10 other cells, and those are triggering other changes
  • Cell dependencies (within the same table OR table two table), other than formula-related cell-to-cell changes
  • Overuse of the render() method. For example, when you are not using the batch() method to alter many cells within one operation.
  • Excessive event listeners can significantly impede performance, often more swiftly than anticipated. It is imperative to thoroughly review whether your table is burdened with an overabundance of event listeners, as this can notably hinder its functionality.

or maybe a combination of more than one factor.

#10