December 15, 2015 at 11:48 am Virtual Scrolling increase recordendindex and recordstartindex #79320
My sample database table contains 750000 rows. When I scroll down 3-4 rows, Grid will call the server again. I want to increase the server load gap. Current gap shows 19 (recordendindex – recordstartindex). I have given pagesize:50, it did not work. I am following This Demo
December 15, 2015 at 12:00 pm Virtual Scrolling increase recordendindex and recordstartindex #79322
- This topic was modified 6 years, 9 months ago by supun151515.
pagesize affects Paging only so turn on Paging if you want it to have effect.
http://www.jqwidgets.comDecember 15, 2015 at 12:17 pm Virtual Scrolling increase recordendindex and recordstartindex #79323
I don’t want paging. Datagrid virtual scrolling gets 18 rows at a time. I want to make it 50 at a time. So it will not call the server everytime I scroll I hope.
SupunDecember 15, 2015 at 12:29 pm Virtual Scrolling increase recordendindex and recordstartindex #79324
There is no solution then.
http://www.jqwidgets.comDecember 15, 2015 at 12:37 pm Virtual Scrolling increase recordendindex and recordstartindex #79325
I wonder that we can’t edit server calls, My grid calls the server for every 1 or 2 clicks on scroll down button. This is really a big issue.
Hope you will find a solution
SupunDecember 15, 2015 at 12:42 pm Virtual Scrolling increase recordendindex and recordstartindex #79326
I wrote you what is the solution and it is to turn on Paging if you want to request records depending on the “pagesize” param. If you want scrolling, the Grid will make requests when it needs records and this is by design which will most probably not be changed.
http://www.jqwidgets.comSeptember 7, 2016 at 9:05 am Virtual Scrolling increase recordendindex and recordstartindex #87157
supun151515, I just implemented a caching solution that intercepts the server calls in the loadServerData callback method. I specify one parameter that is a window size about three times the viewable size, and if the user scrolls close enough to the end of the cache, it asynchronously loads the next chunk of content and has it ready just in time before the user scrolls there. I also have some special provisions to expire the cache explicitly and with a maximum lifetime parameter.
You are right, by default the server calls are excessive, request redundant data, and create a poor user experience. The approach I just coded and tested works so well that the users only see the loading spinner upon page load, scrolling very far quickly, and filtering and sorting. It creates a cache for each hash of the sort and filter parameters. With the timed expiry, it’s not a giant memory leak. Even without that, it still uses way less memory than we did before when loading the entire data set up front.
I’m still seeing a little flicker when it renders, but I have an idea to try before giving up on that.
I’d love to post my code, but I’m not at liberty to do so. The idea is sound and a solution can be had if you’re willing to code it!September 7, 2016 at 11:49 am Virtual Scrolling increase recordendindex and recordstartindex #87164
Our idea is to do not cache anything and that was the reason it is coded in that way.
http://www.jqwidgets.comSeptember 8, 2016 at 7:54 pm Virtual Scrolling increase recordendindex and recordstartindex #87207
While the provided client-side grid features, especially filtering, mostly work (with the glaring exception of a string != condition), the slow performance became a real showstopper once our data sizes became interesting. By doing these features server-side with a virtual mode grid, we were able to deliver good interface response time once I implemented the solution I described above. It’s not much more of a cache design than the data adapter’s records property, but it’s a tiny layer meant to feed the poorly designed request mechanism that calls loadServerData more frequently than necessary.
Really, it’s just a simple look-ahead with sequential read access instead of redundantly re-reading most of the data plus tiny increments of new data.
Like driving a car with one’s eyes open instead of shuffling one’s feet blindfolded with their hands out.November 14, 2018 at 2:56 pm Virtual Scrolling increase recordendindex and recordstartindex #102760
Any updates on this? It is really pointless to have virtual scrollbar having to query data on every click.November 14, 2018 at 4:10 pm Virtual Scrolling increase recordendindex and recordstartindex #102764
It depends on the application’s needs. We do not have caching of loaded data in that mode. It requests data on each scroll. In case of paging and virtual mode, on each change of the page index.
http://www.jqwidgets.comDecember 13, 2018 at 10:20 pm Virtual Scrolling increase recordendindex and recordstartindex #103196
Let me chime in and say this is exactly what I’m looking for as well. It needs to essentially be “virtual paging”. The scrollbar should be the length of all the totalrows, but download a “page” of data at a time. Once you scroll down past the data you already have, it should request a new page of data. That lets the grid be responsive for a portion of the data, and not continually reloading data we already have.
The way virtualmode is now, the grid will request the 20 visible rows and one down scrollbar click will then request 19 of the same rows from the server and 1 new one. It is very choppy. It should request the next 20 and then have all 40 available so the grid is fast and responsive while moving between those 40 rows, and it shouldn’t need to request anything until you get to a row you don’t already have, in this case the 41st row.
TP_DTNA – I understand you can’t post your code, but would it be possible to write a little pseudocode or get us started? Did you bind to a localsource array the size of totalrows so the grid would be responsive, and then somehow trigger server-side events manually when rows aren’t filled in or something? Just trying to figure out how the source was set up and which methods should implement what.
You must be logged in to reply to this topic.