🚀 go-pugleaf

On Thu, 04 Nov 1999 09:55:42 +0000, Steve Horsley wrote:

Thank you for your excellent answer, Steve.  It will be very helpful.

> I would suggest that you arrange that all the model observers do not
> modify the GUI directly, but instead create a Runnable object that will
> do the work. You can then use SwingUtilities.invokeLater(Runnable r) to
> have the GUI update performed by the GUI event thread.

This is close to (but much better than) one idea I had thought of.  I was 
considering creating two event registration methods for each one I have 
now.  Listeners registered with one method would have worked the same as 
it does now, while the other would have used invokeLater() to notify the 
listener.  Your suggestion is much cleaner.

There are a few issues that must be considered with this approach.  One 
is that the GUI update code will no longer be executed when the event is 
fired.  Again, your approach is cleaner in this regard:  My approach 
required that the event information was not dependent on the current 
state of the model since when the Listener received it, the model may 
have changed.  With your approach, the Listener can determine precisely 
what information is needed to update the GUI, and queue it with the 
Runnable.

One concern I did have was with performance.  Do you have any idea what 
kind of overhead is incurred when you use invokeLater()?  From my brief 
glance at the source code, it does not look too bad, but it's hard to 
tell without actually trying it.

One possible optimization on this would be to have the listeners check 
whether they are already running on the event dispatch thread using 
EventQueue.isDispatchThread(), and perform the update without queuing if 
this returns true.

-- 
John P. McGrath
<mcgrath@enter.net>
<jpm@nscs.fast.net>