I need to display "too many" (like 20k) entries in a JFace ComboViewer. Measurement shows, that populating the combo takes multiple seconds, and depending on the UI I have several such combos on the screen - so opening some panels takes > 10 sec. Data to be set are already cached. So it is really not about DB-Loading performance, but just about populating ComboViewer (doesnt matter if I use Combo or CCombo underneath).

I thought about the following, but no solution really seems to work for me.

1. Use SWT.Virutal. First I thought "that's it", just to find this is only supported for Table and Tree.
2. Populate content from a background thread. This doesn't seem to work as both Combo and CCombo.setItems only work if invoked from the UI thread.
3. Populate from a background thread. Split data into Junks. Trigger the UI thread to add each Junk. This seems quite complicated and error prone, but at least an idea I didn't try yet.
4. Use a different control (ok, which?).
5. Re-implement ComboViewer to either support SWT.Virtual or at least allow population from another thread but the UI thread. ... here I think this is the solution causing most effort.

I have no obvious other ideas. Did anyone else run into a similar situation, and maybe found a solution to solve it?

I'd love to find a control with a datamodel like e.g. NatTable underneath, which handles "big amounts of data" very well. ComboViewer seems to be the wrong control for such kind of data, but replacing it in an old legacy application again causes quite some work.

Thanks, Chris

I need to display "too many" (like 20k) entries in a JFace ComboViewer. Measurement shows, that populating the combo takes multiple seconds, and depending on the UI I have several such combos on the screen - so opening some panels takes > 10 sec. Data to be set are already cached. So it is really not about DB-Loading performance, but just about populating ComboViewer (doesnt matter if I use Combo or CCombo underneath).

I thought about the following, but no solution really seems to work for me.

1. Use SWT.Virutal. First I thought "that's it", just to find this is only supported for Table and Tree.
2. Populate content from a background thread. This doesn't seem to work as both Combo and CCombo.setItems only work if invoked from the UI thread.
3. Populate from a background thread. Split data into Junks. Trigger the UI thread to add each Junk. This seems quite complicated and error prone, but at least an idea I didn't try yet.
4. Use a different control (ok, which?).
5. Re-implement ComboViewer to either support SWT.Virtual or at least allow population from another thread but the UI thread. ... here I think this is the solution causing most effort.

I have no obvious other ideas. Did anyone else run into a similar situation, and maybe found a solution to solve it?

I'd love to find a control with a datamodel like e.g. NatTable underneath, which handles "big amounts of data" very well. ComboViewer seems to be the wrong control for such kind of data, but replacing it in an old legacy application again causes quite some work.

Thanks, Chris

• swt
• eclipse-rcp
• rcp

• Maybe Eclipse Nebula tablecombo – greg-449 Commented Feb 14 at 15:05
• 1 How precisely are you expecting users to sift through a dropdown with ~20k entries to the single value they want? The answer might help with suggestions for alternative controls--or even bigger UX changes, like a regular text field with an automatically triggered content assist proposal list once more than two characters are entered, still available when nothing's entered, filtering down further if they keep typing, with the contents giving validation feedback if they haven't typed in 150ms or so. – nitind Commented Feb 15 at 3:25
• I simplified my setup. In realty my combos are more complex and I use them together with ContentProposalAdapter. This way user can easily search for the values using type-ahead, but still can just select the provided set of values. Further the UI is consistent, independent of the number of entries. – Chris Lewold Commented Feb 15 at 10:09

1 Answer 1

I finally solved the problem like this:

• Delegate Loading code to a ComboFiller class.
• ComboFiller delegates loading to a thread (in case a given limit of items is exceeded).
• The thread splits the items into junks of a given size (I took 1000). It delegates adding each junk back to the UI thread using Display.getDefault().asyncExec().

This way loading "one big set of values" doesn't block the UI thread for multiple seconds; the UI remains useable.

Care has to be taken when setting the currently selected item - this has to be postboned until the loading thread is finished.

I would have preferred to use a concept like SWT.Virtual. Unfortunately the API isn't perfectly consistent between controls.