[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-swt-dev] Large Tables
|
> I am writing a standalone SWT app on Windows, and require a table that
holds a
> large number of rows (possibly as many as one million) with 10 columns.
> Has anyone got any better ideas, and which is the best way to go forward
from here?
Matthew, Presenting a very long list as a Table widget is not practical
for reasons other than the purely technical SWT problems you're struggling
with. Even if there was a perfectly working implementation of a million-row
table, a scrollable table with anything over a couple of hundred entries
would still be judged to be unusable by most human beings. If your users
have as many as a million entries to choose from, they'll clearly need some
sort of search capability. I suggest looking around for other UIs that
present long lists (phone books, dictionaries, web search results) to see
how they approach it. Once you've found a have a workable UI design, you
won't have to fight SWT so much.
---Jim des Rivieres
"Matthew Golby-Kirk"
<Mgk@xxxxxxxxxx> To: platform-swt-dev@xxxxxxxxxxx
Sent by: cc:
platform-swt-dev-admin@ Subject: [platform-swt-dev] Large Tables
eclipse.org
10/22/2002 11:59 AM
Please respond to
platform-swt-dev
Hi All,
I am writing a standalone SWT app on Windows, and require a table that
holds a
large number of rows (possibly as many as one million) with 10 columns.
Now using the Table / TableItem classes, the time taken to initialize the
table
with all the data in one go takes too long, when the number of rows exceeds
about 15,000 on my machine (1.8Ghz P4, 1GB RAM WinXP), and when I exceed
160,000
entries it took over 2.5 hours to draw the table.
I have had two ideas as to ways to combat this, but both have problems, and
I would
like opinions on how others may have solved this problem.
Idea 1: Write a viewport class that only shows the first 100 rows, then
hook the vertical
scroll bar with a listener , reset the maximum entries in the scroll bar
and redraw the
data in the table on each scroll event.
Now I have written the class ok, but cannot seem to hook all the events
correctly,
as the table appears to reset the scroll bar's size and selection without
sending an event,
so my viewport scrollbar's thumb seems to go from being small to large
without my being able to control it properly.
Idea 2: Subclass Table (which I know is not a good idea but I wanted to see
if I could
at least make things better) with a new LargeTable class and try to improve
the speed
at which things occur in the parent table by overriding methods.
Doing this I have improved the speed of showing 160,000 entries from 2.5
hours to 15 minutes
simply by adding a setNumberItems(int size) method that resized the items
vector in one go,
rather that incrementing the items vector by 4 each time as the standard
Table code does.
However this is still too slow really.
Has anyone got any better ideas, and which is the best way to go forward
from here?
I have sample code I can post if it would help explain what I an trying to
do in each idea...
Kind Regards,
MGK
-
Matthew Golby-Kirk MQSeries Integrator Development
Hursley Park MP 211 IBM UK Internal 24-6700
Internet:: mgk@xxxxxxxxxx, Notes: Matthew Golby-Kirk/UK/IBM
Phone: +44-(0)-1962-816700 Fax: +44-(0)-1962-816898
http://muppet.hursey.ibm.com
"Skating away, on the thin ice of a new day..."
