November 2011


Options: Use Proportional Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Sean Luke <[log in to unmask]>
Reply To:
MASON Multiagent Simulation Toolkit <[log in to unmask]>
Thu, 17 Nov 2011 10:59:29 -0500
text/plain (26 lines)
On Nov 16, 2011, at 7:21 PM, Ge wrote:

> According to the MASON manual, it says that the display should be updated 
> by it self which means I don't need to bother to schedule the drawing.
> But in reality I trid to rely on the customized portrayal(handles drawing by 
> itself without delegatoin to the simple portrayal) to update based on the 
> underlying field value change, it didn't work. Nothing was updated.
> The sample files packaged with MASON never shceduled the drawing 
> mechanism and they all updated properly.
> So if we add customized portryayal the updating of GUI has to be done by 
> explicitly scheduling the drawing?

Nope.  When you create a Display2D, one of the first things it does is schedule itself on the GUIState's minischedule (by calling reset() on itself).  Here's how that affects redrawing. 

Each time the Console iterates, it steps the GUIState's minischedule.  This in turn steps the model's schedule, and then steps the Display(s), which are also on the minischedule.  During the Display2D's step() method, it calls repaint() on itself, which puts it in the Swing Event Queue to be redrawn soon thereafter.  When a Display is redrawn by Swing, it clears itself, then calls draw(...) on each of its FieldPortrayals.  That's you.

So it's likely a bug in your code.  Off the top of my head: Have you checked to determine if your draw() method is being called at all?  That'd be the first thing to check.  Did you attach your portrayal to the Display?  Any chance you have another portrayal which is also attached and is overwriting your portrayal entirely?  

> Does the MASON check all the portrayal's dirty flag to determine whether to 
> update at each step?

The dirty flag is only a convenience for certain field portrayals to do some optimization internally.   Some of them use it to determine whether to bother redrawing when their draw() methods are called.  Others ignore the dirty flag and always redraw.   If you're not using it, you're always redrawing.