Feature request: get data in fixed size pages

It would be helpful if we could set a fixed data page size, which can help with http request caching and also avoid the situation where first you request 0-49 and some scrolling later 5-54. This gets worse with smaller scrollY values as the smaller visible area causes more requests (think 0-8 > 1-9 > 2-10 etc.).

So for example, if we have pageSize=50:

1. lets assume that according to the table setup we decide that we should fetch 0-20
2. using the page size we can cover this range with a single page of 50 rows, so we request 0-49
3. later, when we need 5 more rows - ie <something>-54 (49+5), we instead request the next full page that covers it, 50-99.

I am not sure about the best way (least intrusive) to acomplish this. I think a mechanism that requests data in pages and renders all pages that intersect with the current calculated range (so if we need 45-60 we render 0-99).

Also, at this point some internal caching could be helpful so that if we we have 0-49 and we need some extra rows, we won't have to get 0-99, just the extra page of 50-99 and combine them. Not sure though if that's possible.

The pros of this approach are:

• better http caching possibilities
• less overall load
• improved predictability of load (depends on the size of the scrollY less than the current implementation)
• reduction of load during table resize (I use tables in panels that start small [5-10 rows] but have user controls for larger size [20-30 rows] and fullscreen [can reach 50+ rows for spreadsheet like views]).

By the way, to avoid any confusion: when I refer to page size I am not talking about the paging mode (vs scroller). I mean a fixed requested-data length.

The issue does not name files or tests. Start by locating the Scroller code that calculates the visible range and issues data requests, then trace how ranges are rendered and cached. Done means requests use fixed-size pages, intersecting pages render the required range, and already fetched pages can be reused without requesting overlapping data.