Community
Participate
Working Groups
The current IStructuredContentProvider for TableViewer has only one method to deliver the content to the TableViewer (getElements()). However, getElements returns one (sometimes) big array of objects representng the column data. In some scenarios the data to be displayed in the table is very large (e.g. database content) and can't be successfully stored in one single array. Another scenario would be if more data is being appended to the curret data at a very high frequency, resulting in the allocation of a new array (containing n+1 entries) everytime a new data row is being appended. This can leed to very high memory load and poor performance. Therefore we need a more sophisticated ContentProvider (e.g IRowDataContentProvider) with a method like "Object getElementAt(int row)" or "Object[] getElementsAt(int startRow, int endRow)" and another method like "int getNumberOfElements()" that allows us to retrieve only that data, that is visibe at the moment. This is inprired from the way the Swing DefaultTablModel works. But in contrast to DefaultTableModel where the cell data is retrieved, the enhanced ContentProvider would retrieve full rows which would fit more closely into the exisiting JFace/SWT model and would not decrease performance too much when scrolling in tables. A highly advanced TableViewer could cache some rows outside the current view area so that the ContentProvied isn't called that often when the user is scrolling.
There are no plans for the UI team to work on this defect until higher priority items are addressed. If you would like to work on this defect, please let us know on the platform-ui-dev mailing list. Note that this will require a new kind of table widget from SWT which allows for lazy population.
See ILazyContentProvider added in 3.1. which is designed for use with the VIRTUAL table which only gets the visible items. Object getElementAt(int row) is possible with the method updateElement(int index) Object[] getElementsAt(int startRow, int endRow)is not implemented because the OS asks for items one at a time. You may want to batch your updates but it would be pointless for us to give it to you are startRow and endRow would always be the same. getNumberOfElements() has OS issues as well as the indicies requested by the OS are not sequential if the user scrolls quickly. You could keep the last index if that suited your algoirthm but the number of elements that were visible at any time is a list of grouped items. An implementation of ILazyContentProvider (DeferredContentProvider) is also avialable that supports filtering and sorting as well. Adding Stefan Xenos as he is the author and so may be interested in this discussion. I am going to mark this fixed as I think we have provided what you are after within the limits of the OS in 3.1.
Marking as closed.
