Community
Participate
Working Groups
Build ID: I20080609-1311 Steps To Reproduce: 1. Make a virtual Table with enough items (say 3 Million). 2. Wait say 20 seconds for setItemCount(). More information: As far as i understand the problem is that for each item is preallocated, which kinda defeats the purpose of being virtual. import org.eclipse.swt.*; import org.eclipse.swt.widgets.*; import org.eclipse.swt.layout.*; public class setitemcount { static final int ROWS = 3000000; public static void main (String [] args) { final Display display = new Display (); Shell shell = new Shell (display); shell.setLayout (new FillLayout ()); final Table table = new Table (shell, SWT.VIRTUAL); table.setHeaderVisible (true); table.addListener (SWT.SetData, new Listener () { public void handleEvent (Event e) { TableItem item = (TableItem) e.item; item.setText ("test"); } }); TableColumn column = new TableColumn (table, SWT.NONE); column.setText ("Column 1"); column.setWidth (80); long start = System.currentTimeMillis(); table.setItemCount (ROWS); System.out.println("" + (System.currentTimeMillis() - start) + "ms"); shell.open (); while (!shell.isDisposed ()) { if (!display.readAndDispatch ()) display.sleep (); } display.dispose (); } }
This might be the best we can do. GTK doesn't directly support virutal tables. Can you include the GTK version and the hardware and memory specs for your machine?
This is a Core2Duo (T5300 @ 1.73GHz) Notebook with 2.5GB RAM (DDR2-667MHz) running Archlinux 32bit. The GTK version is 2.12.9.
Performance on GTK3.22 is ~7 seconds. As comment 1 mentions, this is pretty good considering GTK doesn't officially support lazy loading. Due to age I am going to close this bug, as I don't think it's reproducible. Please feel free to file a new bug if the issue persists.
Please also take a look at this analysis: http://stackoverflow.com/a/43792401/241453
There has been done a detailed analysis which points out some possible SWT improvements regarding reduction of native calls, but finally boils down to the already mentioned problems in GTK design: http://stackoverflow.com/a/43792401
(In reply to Marc Strapetz from comment #5) > There has been done a detailed analysis which points out some possible SWT > improvements regarding reduction of native calls, but finally boils down to > the already mentioned problems in GTK design: > > http://stackoverflow.com/a/43792401 I am not sure how much can be done about the locking and unlocking. I think it merits some investigation but our hands are tied by GTK.
Created attachment 268312 [details] GTK test application
Created attachment 268313 [details] SWT test application
I've received more details from the author of the SO answer: I've attached an SWT test application for which Table.setItemCount() can be switched between 3 and 10M rows and a GTK test application which simply fills a GtkListStore with 10M rows. According to the author, in his VM switching from 3 to 10M rows in the SWT test application takes ~83s, populating the GtkListStore takes ~15s.
