Real virtualisation

michaelkaldeck

Hi
while scroller makes it possible to scroll through large tables, it seems to have limitations like fixed rowheight, not on the roadmap for Your newly started grouping api/features.
I wonder if this is all a consequence of the basic rendering model which is html table based.
Is that the case ?
* If yes,
* Would this be the base of real virtual general scrolling? (like you render only what you need in the portion that is visible)
* would a change to div based rendering, even with own scrollbar (jqxGrid, ag-grid etc) solve these problems.
* And would this in general allow for features like "rowheight dependent on content", "user can change rowheight"
* Is such a fundamental change for You basically desirable and something You would consider?

Please let me know Your thoughts
Thanks in advance, Michael

allan

Its a consequence of how Scroller calculates the position. For example, if you want to scroll to row 50'000, and you know that every row is 30px, then you know that you can jump to 1'500'000px (assuming linear calculations - Scroller actually does non-linear positioning for tables which are large enough).

Now consider what would happen if row index 34'567 just happened to be 90px while all the others were still 30px. That would knock all rows after it out of alignment.

As such Scroller assumes that all rows are the same height.

The only other way I can see around this is to have knowledge of the row heights a priori. We would likely need to render every row to determine its height - and thus any speed benefit of Scroller has been lost.

Allan

chdh

For scrolling and rendering very large virtualized tables, the exact row height could be only determined (and cached) for the rows in the viewport region and the other rows could be assumed to have the default height.