🚀 go-pugleaf

I have not noticed any performance issues with this method, although
there obviously are some. Keeping a GUI up to date does not require 
millisecond response times, so queueing an update to another thread
does not make a visible difference. You are creating new objects 
though, and they have to be garbage collected later, so there must be 
a slight performance penalty. If you are only showing a progress 
indication of some sort occasionally, I guess this penalty is small-
to-irrelevant. 

The hardest work I have done like this was a test packet generator/
listener. It sent/counted multicast packets. It had problems at
over 2000 packets/sec, but I think the problem was more likely the
packet reception/decoding than the update of the counter in the GUI.
I suppose I could have taken steps to ensure the GUI was only updated
maybe once every 100mS.

I have never bothered to check if I am on the event thread before
using invokeLater. In everything I have written invokeLater in, it
has always been pretty obvious that I will not be on the event 
thread anyway. In the example above, the counter changes were always
caused by the transmit timer thread (transmit packet count)
or the socket listener thread (rx packet count). I think that 
performing this check is more likely to waste time than save it.

Steve.
//-----------------------------------------

"John P. McGrath" wrote:
> 
> 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>