omom
asked on
2 threads
Thinking about the design of a application with 2 threads on the client side, where one thread is the UI and one thread is a worker thread that talks with the server.
I can think of 3 ways to set it up:
1. main() starts the UI thread and the worker thread
2. main() starts the UI thread which in turn starts the worker thread
3. main() starts the worker thread which in turn starts the UI thread
Originally, I started out with 3, but now I am thinking it should be 2.
In recent reading, I think I saw 2 being used with the Java class SwingWorker. Is SwingWorker truly viable, or is it more of a textbook example?
I can think of 3 ways to set it up:
1. main() starts the UI thread and the worker thread
2. main() starts the UI thread which in turn starts the worker thread
3. main() starts the worker thread which in turn starts the UI thread
Originally, I started out with 3, but now I am thinking it should be 2.
In recent reading, I think I saw 2 being used with the Java class SwingWorker. Is SwingWorker truly viable, or is it more of a textbook example?
ASKER
Yes, I'm talking Swing application.
(I started out with SWT but I'm thinking of abandoning it)
The requirements, at a high level, are simple. The client sends a command to the server, the server does some number crunching and/or database access, then sends some data back to the client, then the client displays an image based on that data.
(I started out with SWT but I'm thinking of abandoning it)
The requirements, at a high level, are simple. The client sends a command to the server, the server does some number crunching and/or database access, then sends some data back to the client, then the client displays an image based on that data.
in that case i'd have a thread handling sending commands to the server, and notify listeners when events of interest occur. The listener could then handle updating gui as required. This way the comms thread does not have to know anything about the gui.
PS. How did you find SWT?
PS. How did you find SWT?
for omom: if you're talking Swing, you can't control which thread is the event dispatching thread(UI thread)
It's different from SWT, where your evt disp. thread can be controlled, and you have to loop for your own messages.
For objects:I've done a little benchmarking on SWT vs. Swing. I happened to be a SWT enthusiast for a few days, but it was better than Swing just at opening new frames.
I paste the results over here:
30 frames shown,then dispose
SWT 0.2s <-> Swing 0.49s
300 Frames show,then dispose
SWT 4.1s <-> Swing 7.8s
10000 oval drawing
SWT-7.8s <-> Swing 7.2s(without double buffering)
Button adding(100 buttons at a time)
Swing:
Entire process:0.171 Entire process:0.13 Entire process:0.14 Entire process:0.12 Entire process:0.12 Entire process:0.13 Entire process:0.15 Entire process:0.311 Entire process:0.161
SWT:
Entire process:0.11 Entire process:0.07 Entire process:0.09 Entire process:0.11 Entire process:0.13 Entire process:0.15 Entire process:0.16 Entire process:0.201 Entire process:0.21 5000 buttons on a form:
SWT - 6.4MB memory,terrible refresh
Swing - 12.4 MB memory,very good refresh(due to double buffering)
//////////
Note: the tests were taken with double buffering disabled,if I'd leave it on, Swing would have kicked ass.
Conclusions:
This kind of benchmarking makes Swing look better.There are some tests I couldn't perform which would involve responsiveness(time between click and response, delay induced by GUI code,since Swing is kinda "heavyweight").
I'd personally go with Swing...at least until SWT gets some more background and community support.
P.S. Sorry about the layout of this reply, it's taken from a mail to one of my colleagues(which was in turn pasted from my benchmark app).
Regards.
It's different from SWT, where your evt disp. thread can be controlled, and you have to loop for your own messages.
For objects:I've done a little benchmarking on SWT vs. Swing. I happened to be a SWT enthusiast for a few days, but it was better than Swing just at opening new frames.
I paste the results over here:
30 frames shown,then dispose
SWT 0.2s <-> Swing 0.49s
300 Frames show,then dispose
SWT 4.1s <-> Swing 7.8s
10000 oval drawing
SWT-7.8s <-> Swing 7.2s(without double buffering)
Button adding(100 buttons at a time)
Swing:
Entire process:0.171 Entire process:0.13 Entire process:0.14 Entire process:0.12 Entire process:0.12 Entire process:0.13 Entire process:0.15 Entire process:0.311 Entire process:0.161
SWT:
Entire process:0.11 Entire process:0.07 Entire process:0.09 Entire process:0.11 Entire process:0.13 Entire process:0.15 Entire process:0.16 Entire process:0.201 Entire process:0.21 5000 buttons on a form:
SWT - 6.4MB memory,terrible refresh
Swing - 12.4 MB memory,very good refresh(due to double buffering)
//////////
Note: the tests were taken with double buffering disabled,if I'd leave it on, Swing would have kicked ass.
Conclusions:
This kind of benchmarking makes Swing look better.There are some tests I couldn't perform which would involve responsiveness(time between click and response, delay induced by GUI code,since Swing is kinda "heavyweight").
I'd personally go with Swing...at least until SWT gets some more background and community support.
P.S. Sorry about the layout of this reply, it's taken from a mail to one of my colleagues(which was in turn pasted from my benchmark app).
Regards.
ASKER
>>How did you find SWT?
I don't really have enough experience to compare the SWT to Swing. However, cavey79 expressed my first thought..."personally go with Swing...at least until SWT gets some more background and community support." Being of limited intelligence, I need lots of examples and such. This is not the fault of anyone developing SWT, its just very young. I do applaud the developers of the SWT with the effort to improve the UI aspect of Java.
Thanks to cavey79 for the stats.
I don't really have enough experience to compare the SWT to Swing. However, cavey79 expressed my first thought..."personally go with Swing...at least until SWT gets some more background and community support." Being of limited intelligence, I need lots of examples and such. This is not the fault of anyone developing SWT, its just very young. I do applaud the developers of the SWT with the effort to improve the UI aspect of Java.
Thanks to cavey79 for the stats.
Actually I was kinda impressed by SWT and the whole idea behind it(there are some pretty articles available describing the architecture).Unfortunatel
SWT isn't a cure for slow interfaces, the truth is you have to know Swing well to design responsive interfaces. These are the two sides you will find in any argue over SWT and Swing. Swing fans say you have to know Swing to do right, SWT fans say Swing crawls and SWT kicks *ss.
I'm curious if anybody has done some benchmarking of their own...I'd like to see some linux results(I tested on a Win2K), cause I got no time for this anymore :(
Regards.
SWT isn't a cure for slow interfaces, the truth is you have to know Swing well to design responsive interfaces. These are the two sides you will find in any argue over SWT and Swing. Swing fans say you have to know Swing to do right, SWT fans say Swing crawls and SWT kicks *ss.
I'm curious if anybody has done some benchmarking of their own...I'd like to see some linux results(I tested on a Win2K), cause I got no time for this anymore :(
Regards.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Omom,
I must apologize too for going the swt vs. swing direction :)
objects, SWT does not apply for applet use, since it uses native libraries...of course you could put those libs inside jre\lib and you could run the applet...of course with sufficient rights(modify the policy file also).
It's just not worth it...
I forgot...it's a very nice approach the SWT guys have taken(ibm of course) in separating the native code...both the java part and the native part are different...you should get the jar appliable to your platform and your platf. specific libraries.As far as I know, AWT has the same java implementation, only the native part differs.
If you have the time, read this
http://www.eclipse.org/articles/Article-SWT-Design-1/SWT-Design-1.html
Regards.
I must apologize too for going the swt vs. swing direction :)
objects, SWT does not apply for applet use, since it uses native libraries...of course you could put those libs inside jre\lib and you could run the applet...of course with sufficient rights(modify the policy file also).
It's just not worth it...
I forgot...it's a very nice approach the SWT guys have taken(ibm of course) in separating the native code...both the java part and the native part are different...you should get the jar appliable to your platform and your platf. specific libraries.As far as I know, AWT has the same java implementation, only the native part differs.
If you have the time, read this
http://www.eclipse.org/articles/Article-SWT-Design-1/SWT-Design-1.html
Regards.
ASKER
no apologies necesary, good info
A UI thread already exists and you don't have to worry about starting it.
So I'd go with:
4. main() starts the worker thread
SwingWorker is usable, though it may depend on your exact requirements whether it'll meet your needs.
:)