[Repast-developer] Network surgery and some threading questions

[Nick C. <nic...@ve...>]

Hi,

Those of you that monitor the commits to the repast cvs archive will
have noticed a flurry of activity on my part. Here's the scoop.

I redid the accessor methods on NonGridDrawable to work with doubles
instead of ints. This required changes in lots of Node drawing classes
and interfaces that extend from this. This will also break any user code
that doesn't use repast provided node drawing classes. So, why then did
I do this.

1. These are NonGridDrawables so, semantically, their coordinates need
not be discrete integers. Its Network2DDisplay that needs to transform
their x and y coordinates into pixel coordinates and so the double to
int transform should be done there.

2. The GraphLayout classes work with doubles and a lot of the work they
do disappears when these doubles are used as integers.

3. I've implemented a new Zoomable interface for displays. You can now
drag a box around nodes and zoom in on them. In order for this to work
correctly we need the double coordinates from graphlayouts rather than
these coordinates rounded into integers.

I've updated the two network example models to reflect these changes.
One worked out of the box, and the other needed a only a few changes.

The other major change in the new code concerns threading. Some
background:

1. All drawing and other gui events in Java are handled via the event
thread. Drawing, that is, painting components, from threads other than
this one must use this thread to do the drawing.

2. RePast models make use of two threads relevant to this discussion.
The first is the gui thread mentioned above. Button clicks, etc. occur
through this thread, just like any other application. All model
activity, execution of actions etc. take place in another thread, the
RunThread. 

The recent changes effect how this RunThread works together with the
event thread in visualizing models. More specifically this refers to
calling updateDislay from within your model, that is, from with the
RunThread. The old code used SwingUtilities.invokeLater() to post the
paint event to the event thread. This worked fine with all code except
when using the KamadaKawai graph layout. Removing invokeLater and doing
a direct paint from the RunThread removed the problems with KamadaKawai.
This was particularly stupid on my part as it caused all kinds of
threading problems. So, this change only lasted a few days. The
currently commited code uses SwingUtilites.invokeAndWait(). This works
synchronously with the event thread as opposed to invokeLater which
works asynchronously. This fixes the problems with KamadaKawai and
allows the RunThread to work correctly with the event thread. However,
it is canonical to use invokeLater over invokeAndWait, so before I go
nailing anything to the church door I'd appreciate any comments.

The problem with KamadaKawai is that it contains lots of computationally
intensive loops and also calls updateDisplay (and thus invokeLater) from
within those loops. Consequently, lots of paint events get posted to the
event queue. So when the run thread goes to check the state of the event
queue it has to wait a long time for these paint events to be handled.
This in itself is not so bad, but the delay causes the toolbar, the
display and the parameter panel to get out synch with the runthread such
that it looks like the RunThread, and thus your simulation is paused or
stopped and ready to accept input (button clicks etc.) when it is not.
Its futzing with the display events in the event queue. 

Nick

-- 
Nick Collier 
Social Science Research Computing
University of Chicago 
http://repast.sourceforge.net