Bug 343419

Description germund 2011-04-20 10:21:48 EDT

Build Identifier: 20110218-0911

I've implemented a table editor using TableViewer, editing support API, TableViewerEditor for navigation and focus-cell-highlighting, StyledCellLabelProvider, sorting, and filtering etc. (Runs within an IEditorPart in the workbench.)

The problem is, that already when there are > 15 columns and > 100 rows scrolling V/H gets "slow" with latencies of several 100ms. The same goes for row-selection updates and re-drawing of the focus-cell highlighter when using page up/down, moving to first/last column, using the scroll bars etc. As long as there are ~10 columns and 200-300 rows I regard the responsiveness to be "acceptable". (I do disable redraw of the control whenever possible.)

It seems like the number of columns makes the biggest difference. And currently when I edit a table I hide as many columns as possible, as 30-40 columns is not unusual in our application. Also, resizing the editor area makes quite a difference.

For testing with just the "basics", I set up the table viewer with a WritableList as its input (simply a list of strings), and I've had the cell label-providers (per viewer column) initially return a hard coded string. The content provider is the ObservableListContentProvider.

I've already seen Bugzillas related to this subject, and some duplicates, but
found no conclusive or active "parent" issue, so I try posting a new one. The editor does not need to be able to handle hundreds of columns and thousands of rows, but IMHO, ~50 columns and ~1000 rows should really not be a problem?


Reproducible: Always

Steps to Reproduce:
The attached .zip contains a simple implementation that creates a table with 46 columns and 300 "initial" rows, editing support, and focus-cell-highlighting. Import the project, start a run-time eclipse, create a file with the extension .tabledemo and open the file with the "Sample Table Editor".