Re: How to change JPanels?
On 2/17/2011 11:12 AM, Eric wrote:
....
So there are multiple EDT threads but there is only one because it
ties them together. If the main JFrame object is started with an EDT
as it is here we have an EDT thread, then when the other threads do
their EDT processing they interrupt it. So if that window thread has
something to do when a worker thread is ready to execute it's done
method that worker should wait until that main (EDT) thread is idle
(listening for events).
I think this paragraph may contain some of the assumptions that are
confusing you. You seem to be assuming dedication of threads to
components. That isn't how it works.
Here is an alternative big-picture model of how the EDT works. I do not
claim it is technically accurate. Indeed, the technical details are
implementation dependent.
The EDT is driven by a queue. It sits in a loop roughly of the form:
while(not time to stop) do
take the oldest message from the queue.
call the things that need to be called to deal with it
done
One type of message says "execute this Runnable's run() method".
SwingUtilities.invokeLater() just pushes that sort of message on the
queue and returns. When the message gets to the head of the queue, the
EDT calls the run() method. invokeAndWait() waits until the EDT has
executed the run() method, rather than returning immediately.
Most of the messages are about GUI events: "The mouse has moved to this
position", "The capital A key has been pressed", "The right mouse button
has been clicked.". Without going into details of the event handling
flow, when one of those events reaches the head of the queue, it causes
calls to component methods to update the components' states, repainting
as needed, and also calls to listeners attached to the components.
Because all GUI activity is done in one thread, there is no need for
synchronization on the GUI data structures and no concerns with memory
model issues. Also, all user actions will affect the GUI in user action
order, which would be difficult to ensure if there were several event
threads.
The cost of that simplicity is that each GUI event has to wait for all
older messages on the queue before it can make anything happen. There is
no interrupting. Each message is completely processed before taking the
next message from the queue. The GUI remains responsive if, and only if,
every message can be processed quickly, so that the EDT can keep up and
its queue is always short.
Using an invokeLater on a Runnable to create a JFrame and make it
visible is fine. The EDT can create the JFrame, make it visible, and go
back to get the next message from the queue quickly enough that the GUI
appears to react directly to the next event in the queue. Sleeping for
even a second in the EDT would cause a human-visible hesitation in the
GUI's reaction to typing and mouse activity.
Patricia