The flip side of a really small displayBuffer is that there are lots of redraws required, which is very likely what is causing the apparent slow performance in this case, even if each individual one is fast.
Without having a test case to work with this locally, I'm not sure how much more there is I can do. This example shows 50k rows client-side, and it demonstrates the performance I would expect. I'm not clear why on your page it isn't getting to that level.
I would say that scrolling will always be slower than paging in terms of performance - often significantly.
The resize itself will be slow, but once that has been computed, Scroller should return to its normal performance, which appears to be the case in the example I linked to above.
Answers
Thank you - in this profile, the big chunk of time is that Scroller needs to get the (scrollTop position](https://github.com/DataTables/Scroller/blob/089740c2d0f4bc225ec73f0d20dae0301c085709/js/dataTables.scroller.js#L665). That is taking 82mS, which seems around about what I would expect.
The flip side of a really small displayBuffer is that there are lots of redraws required, which is very likely what is causing the apparent slow performance in this case, even if each individual one is fast.
Without having a test case to work with this locally, I'm not sure how much more there is I can do. This example shows 50k rows client-side, and it demonstrates the performance I would expect. I'm not clear why on your page it isn't getting to that level.
I would say that scrolling will always be slower than paging in terms of performance - often significantly.
Allan
OK. I will create test case for you to run locally...
What i noticed recently - the performance of this Scroller is degraded after resize event happened on the grid...
Any idea why it could happened?
The resize itself will be slow, but once that has been computed, Scroller should return to its normal performance, which appears to be the case in the example I linked to above.
Allan