-
Notifications
You must be signed in to change notification settings - Fork 10
Home
The purpose of this table component from servoy-extra-components is to be able to show large numbers of rows with acceptable or fast response times. It is a read-only table.
The table is highly configurable from Properties View - in Developer. It can be configured to do paging and/or incremental scrolling.
You can set pageSize > 0 for fixed page sizes, or pageSize 0 to disable paging; we intend to add pageSize -1 for auto-determining page size based on available height but that is not implemented yet.
This can work together with paging as well, so you can have a large page size and incremental scrolling would still work.
Incremental scrolling means that if many rows are available (hundreds/thousands) only then rows surrounding the ones that need to be shown will be loaded from server and only a part of those will initially be rendered (added to the browser's DOM).
When the user scrolls, more rows will be loaded from server if needed and more rows will be rendered as needed.
The purpose of all this is that, for example, if you have 1000 rows and selected row is 823, we don't send to the browser the data for all 1000 rows and render thousands of cells in browser. Just some rows around the visible area (which initially will show selected row 823) will be loaded and some of them rendered. This can drop initial show time from tens of seconds or minutes (depending also on the data in each column, connection speed, hardware, ...) to less then one second.
Incremental scrolling can be controlled/customized or virtually disabled by modifying the following properties in properties view:
performanceSettings : {
minBatchSizeForRenderingMoreRows: 10,
minBatchSizeForLoadingMoreRows: 20,
maxRenderedRows: 450,
maxLoadedRows: 1000,
fastScrollRenderThresholdFactor : 3.0,
fastScrollLoadThresholdFactor : 2.3
}
The values above are the default values that should be fine for most situations. If you want to tweak them, here is what they mean:
-
performanceSettings.minBatchSizeForRenderingMoreRows: influences the minimum of:
-
how many rows around the initial visible area will be rendered initially;
-
(when scrolling) how many more rows get rendered each time in the direction of the scroll - in advance. This is done so that when the user scrolls, content is prepared for being shown. The default value is 10.
The real value of initial rendered rows and of additional batch sizes for rendering is actually calculated from the visible height that the table has to work with in the browser, but it cannot go lower then what this setting requires.
If you want to disable incremental rendering, just set a very high value for this setting and then all available (loaded from server) rows will be rendered right away (this makes sense when combined with paging - acceptable page size).
-
-
performanceSettings.minBatchSizeForLoadingMoreRows: influences the minimum of:
-
how many rows around the initial visible area will be loaded from server initially;
-
(when scrolling) how many more rows get loaded from server each time in the direction of the scroll - in advance. When the user scrolls, row data is received from server ahead of the scroll so that more rows can be rendered. The default value is 20.
The real value of initial loaded rows and of additional batch sizes for loading rows from server is actually calculated based on the visible height that the table has to work with in the browser, but it cannot go lower then what this setting requires.
If you want to disable incremental loading of row data, just set a very high value in there and then all needed rows will be loaded from server (this makes sense when combined with paging - acceptable page size).
-
-
performanceSettings.maxRenderedRows: in order to not slow down browser UI due to a huge number of DOM elements being created, this limits the number of rows that the table will render.
If the user scrolls a lot and this results in more then 'maxRenderedRows' being rendered - the table will discard a part of the rendered rows and start fresh - as if it was rendering initially around the visible area.
If you set a high value, many rows can get rendered in the browser and then you will have a more natural feel when scrolling fast back to already rendered rows. But if the value is too high and the browser slows down too much it is better to start fresh with less rendered rows more often (so have this set to a lower value).
Default value is 450 (although some browser & hardware can handle nicely even more rendered rows, depending also on content).
-
performanceSettings.maxLoadedRows: in order to not use too much memory in the browser due to a huge number of rows (row data) being loaded, this limits the number of rows that the table will keep loaded.
If the user scrolls a lot and this results in more then 'maxLoadedRows' being loaded - the table will discard a part of the loaded rows.
If you set a high value, many rows can get loaded in the browser and then you will have a more natural feel when scrolling fast back to already loaded rows. But if the value is too high the browser memory usage might grow too much and it is better to discard part of the loaded rows (from the opposite side then user is scrolling to).
Default value is 1000 (although some hardware can handle nicely even more loaded rows, depending also on content).
-
performanceSettings.fastScrollRenderThresholdFactor: Default value: 3.0 (float); if for example you have a table with 1000 rows and initially the selected row is shown at index 700 - rendered rows and loaded rows will be around the visible area. Then if the user grabs the scroll knob with the mouse and drags fast upwards to the beginning we have to discard what we have rendered and render the first set of rows instead.
We cannot just render batches of rows one by one upwards until we reach the first row because that will take a very long time. This setting determines when the table component considers a scroll operation to be a "fast-scroll" that needs a discard of currently rendered rows and a render of the new visible area.
When the scroll position is more then 'fastScrollRenderThresholdFactor * initiallyRenderedRows' apart from currently rendered rows, the scroll operation is considered to need a completely new set of rendered rows.
-
performanceSettings.fastScrollLoadThresholdFactor: Default value: 2.3 (float); if for example you have a table with 1000 rows and initially the selected row is shown at index 700 - rendered rows and loaded rows will be around the visible area. Then if the user grabs the scroll knob with the mouse and drags fast upwards to the beginning we have to discard what we have loaded and load the first set of rows instead.
We cannot just load from server batches of rows one by one upwards until we reach the first row because that will take a very long time. This setting determines when the table component considers a scroll operation to be a "fast-scroll" that needs a discard of currently loaded rows and a load of rows from the new visible area.
When the scroll position is more then 'fastScrollLoadThresholdFactor * initiallyLoadedRows' apart from currently loaded rows, the scroll operation is considered to need a completely new set of loaded rows.
If you modify any of these performance settings, please make sure that:
minBatchSizeForRenderingMoreRows < minBatchSizeForLoadingMoreRows
maxRenderedRows < maxLoadedRows
minBatchSizeForRenderingMoreRows < maxRenderedRows (by a lot)
minBatchSizeForLoadingMoreRows < maxLoadedRows (by a lot)