Force iDisplayLength when Scroller using aaData

jcready

I'm having a couple issues with the Scroller plug-in. First, it seems like Scroller was primarily designed to be used with server-side processing, but since I'm generating the aaData client-side it doesn't make much sense to me why it is still ignoring my iDisplayLength setting. When scrolling down the table, it is very noticeable when it draws the next set of 50-100 rows and replaces what was already there. I would much rather have smooth scrolling for the user than have my application freeze for a split seconds before continuing to scroll.

I would love to have the drawing of the new rows be async (or let me defer the action until the user stops scrolling). But I think a quick fix would just be to let me change the actual number of rows drawn at a time. It doesn't seem efficient to have all the rows in memory, but force the browser to repaint 100 rows every second, when I could be drawing 500 rows at a time and only repainting it a few times.

allan

Interesting - are you using Safari by any chance? Scroller should do an asynchronous draw, and when client-side processing (which actually is the main target for Scroller) it should be really smooth - with one exception tha I've found - safari. For some reason, safari will stop the scrolling of the scroll window when the table is redrawn and pass the momentum on to the parent scrolling area - most frustrating! I need to investigate that sometime soon!

Allan

jcready

I primarily test in Chrome (dev channel) and Firefox (beta channel). There is also a chance my CSS is slowing things down. I'm overriding a couple of your inline styles to achieve the effect of having the header row extend out over the scrollbar on the table's body. I then have to resize the header cells when fnDrawCallback is run.

I also think CSS's box-sizing property is messing up jQuery's measurements. Firefox and Chrome are rendering the widths of the header cells differently with the same widths applied.

allan

Okay - I think I'm with it now - yes indeed allowing more rows to be drawn at a time might be very useful for drawing:

> but I think a quick fix would just be to let me change the actual number of rows drawn at a time.

In the next release of Scroller I'll introduce an option that allows you to vary the 'overpaint' region that Scroller uses (currently its 3 time the display area - with an option you could easily make it 100 or whatever).

Allan

jcready

You are a gentleman and a scholar, Allen. Thank you.