[Advanced-java] window refresh question
Nikolaos Giannopoulos
nikolaos at solmar.ca
Sun Apr 13 15:29:42 2003
> -----Original Message-----
> From: advanced-java-bounces@lists.xcf.berkeley.edu
> [mailto:advanced-java-bounces@lists.xcf.berkeley.edu]On Behalf Of Alvin
> Wang
>
>
> Hi, I am writing a multi-window Java application. It receives
> huge amount of
> data from network and displays in JTables. So basically, it is
> swamped. When
> the users moves the windows, it does not have time to handle the repaint
> events, so the screen smears.
I seem to remember a couple months back that you asked a qustion about
populating a JTable with > 10,000 rows (or something thereof). You
obviously didn't listen to the advice that I offered... maybe once you
realize your only digging a deaper hole you might stop and listen.
> In X-Windows, we can suppress the window events, which means the
> application
This is a kludge that does not address the real problem at hand AND in this
case IMO never will.
> will drop some events if it sees itself far behind. The other way in
> X-Windows is the server can save-behind, which means instead of trying to
> repaint some area, it will save that area for future repaint event.
Same comment. No kludge will work well enough unless you address the real
problem with your app and that is in having huge amounts of server data
streamed to your tables NOT to mention that:
(a) your flooding your network unnecessarily,
(b) your over-working your server unnecessarily and
(c) your application will not scale NO matter how much hardware you throw at
it.
> I am not a GUI expert.
That is quite clear.
> Can any guru give me some suggestions how
You have been given them. Re-design your app to filter the amount of data
that is sent to the gui. Alternatively let the server do the work for you -
i.e. pass it criteria to obtain a smaller set of rows.
It seems like you want to move large amounts of data from a back-end
database to the client *assuming* that you are going to get better
performance because you have all the data offhand. Which is exactly the
wrong thing to do most of the time as you may have instant access to your
data but *have fun* trying to display things to your user (as you are
seeing) amongst other problems like (a), (b), and (c) above.
Just imagine how silly it would be if in doing a search on google - you
first had to dowload their entire database - and you might see your problem.
> to improve
> in Java world, or acheive similar strategies I described above in Java?
Your design will fail in pretty much any language you code it in i.e. You
need to understand this is NOT a language or gui problem, rather your issue
is a fundamental design issue.
Cut your losses. Fix the design and you won't have to worry about the
questions you raised in this post.
--Nikolaos