AWT/Swing Event Threads vs SWT - Rob?

[Gregg Bolinger]

One of the more annoying things about Swing is handling heavy loaded methods from within events fired by a JButton, JMenuItem, etc. We actually had a pretty interesting discussion about it last may.

I am wondering if SWT's event handling addresses this issue or what was done to make this process easier for the developer when handling a large amount of code crunching and repainting of the app itself. What does the book cover in this regard?

[Rob Warner]

In SWT, only the UI thread (the one that created the Display object) can update any UI elements. You can spawn worker threads that chug away, and remain blissfully ignorant of SWT threading rules--as long as you don't have to update the UI.

To update the UI, you use Display.asyncExec() or Display.syncExec(). These methods actually block UI updates, so in practice you spawn a worker thread, do some work, call one of these methods to update the UI, and return to your work.

SWT has some widgets, covered in the book, that take some of the pain out of using asyncExec() and syncExec(). ProgressBar, which displays a standard progress bar control, is the rawest of these: you update it directly (see page 130). BusyIndicator (p. 280) shows a busy cursor while it runs some long-running operation. Finally, ProgressMonitorDialog (p. 626), part of JFace, displays a dialog with a progress bar.

In each case, remember the paradigm: do a bit of work, update the interface to reflect progress, and do a bit more work.

[Weerawit Maneepongsawat]

Originally posted by Rob Warner:
In SWT, only the UI thread (the one that created the Display object) can update any UI elements. You can spawn worker threads that chug away, and remain blissfully ignorant of SWT threading rules--as long as you don't have to update the UI.

To update the UI, you use Display.asyncExec() or Display.syncExec(). These methods actually block UI updates, so in practice you spawn a worker thread, do some work, call one of these methods to update the UI, and return to your work.

SWT has some widgets, covered in the book, that take some of the pain out of using asyncExec() and syncExec(). ProgressBar, which displays a standard progress bar control, is the rawest of these: you update it directly (see page 130). BusyIndicator (p. 280) shows a busy cursor while it runs some long-running operation. Finally, ProgressMonitorDialog (p. 626), part of JFace, displays a dialog with a progress bar.

In each case, remember the paradigm: do a bit of work, update the interface to reflect progress, and do a bit more work.

Is that better than Swing?

[Ko Ko Naing]

Originally posted by Weerawit Maneepongsawat:


Is that better than Swing?

Of course, that's what SWT is more preferrable than Swing in this age...

But there is a trade-off between performance and learning curve of SWT for Swing developers..

[Pradeep bhatt]

But there is a trade-off between performance and learning curve of SWT for Swing developers..

Is SWT difficult to learn?

[Ko Ko Naing]

Originally posted by Pradeep Bhat:


Is SWT difficult to learn?

No, but learning new things always take time... Learning rate depends solely on the individual's intelligence... but SWT got handle management, kinda resource management. So if we do care about the performance of a desktop application, we need to adopt SWT, which is better in performance, but a bit handy...

[Aaron Roberts]

Correct me if I'm wrong, but Swing and SWT use the same methodology to handle UI updates outside the UI/Swing thread?

Both have an asyncronus call and a syncronous call to handle UI updates?

Does SWT have the ability to generate mouse events outside the UI thread? This is one of the issues brought up when doing java games development, that all your I/O for mouse and keyboard comes through the graphics thread and you end up with a bit of a bottleneck.

Regards,
Aaron R>