jQuery UI Widgets Forums Grid Virtual Scrolling increase recordendindex and recordstartindex

This topic contains 11 replies, has 6 voices, and was last updated by  mkrajew 3 years, 9 months ago.

Viewing 12 posts - 1 through 12 (of 12 total)
  • Author

  • supun151515
    Participant

    Hi,
    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

    • This topic was modified 6 years, 9 months ago by  supun151515.

    Peter Stoev
    Keymaster

    Hi supun151515,

    pagesize affects Paging only so turn on Paging if you want it to have effect.

    Best Regards,
    Peter Stoev

    jQWidgets Team
    http://www.jqwidgets.com


    supun151515
    Participant

    Hi Peter,
    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.

    Thank You,
    Supun


    Peter Stoev
    Keymaster

    Hi supun151515,

    There is no solution then.

    Best Regards,
    Peter Stoev

    jQWidgets Team
    http://www.jqwidgets.com


    supun151515
    Participant

    Hi Peter,
    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

    Thanks,
    Supun


    Peter Stoev
    Keymaster

    Hi supun151515,

    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.

    Best Regards,
    Peter Stoev

    jQWidgets Team
    http://www.jqwidgets.com


    TP_DTNA
    Participant

    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!


    admin
    Keymaster

    Our idea is to do not cache anything and that was the reason it is coded in that way.

    Best Regards,
    Peter Stoev

    jQWidgets Team
    http://www.jqwidgets.com


    TP_DTNA
    Participant

    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.


    pablodg
    Participant

    Any updates on this? It is really pointless to have virtual scrollbar having to query data on every click.


    Peter Stoev
    Keymaster

    Hi pablodg,

    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.

    Best Regards,
    Peter Stoev

    jQWidgets Team
    http://www.jqwidgets.com


    mkrajew
    Participant

    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.

Viewing 12 posts - 1 through 12 (of 12 total)

You must be logged in to reply to this topic.