My preferred environment before Java was C, so I too had the long
ingrained habit of saying "function" instead of "method."  I never did
much C++, so I don't know whether the OO aspect would've caused any
shift or not.  :-)

I may have misread the original post and simply *assumed* that your
SelectCity code was drawing.  On re-reading, I see that you said only
that it determines what was to be displayed and that paint() "renders
the view".  Apologies if I misinterpreted.

But the off-screen buffer concept that I described is what we use in our
application, and I've learned a great deal about its advantage over the
time I've been working with it.  Ours is a modeling and simulation
application that maintains its "model" in an XML document.  As user
actions and other things occur, they result in the firing of property
change events that cause the BufferedImage to get redrawn.  Any time
that buffer gets changed, the code that does so will also invoke
repaint() on the corresponding JPanel.  When the system determines a
need to paint that same panel, it ultimately does the same.  The result
is that the paintComponent code does little more than simply draw
whatever is currently in the BufferedImage onto the Graphics object
which is provided as a parameter to the paintComponent method.

Hope I was able to help.

= Steve =

This has very serious implications. If your SelectCity() method adds/removes
components from the GUI then it *must* be running in the event dispatch thread.
If it isn't the consequences can be quite dramatic. For reasons see the Java
tutorial on Swing. But imagine the scenario where the EDT is re-drawing the
screen at the same time as the code in your thread is adding/removing
components? Chaos results. Also, if you add/remove components from outside the
EDT then the EDT doesn't know it needs to update the screen so you likely won't
see them being added/removed until the next time the EDT decides it needs to
update the screen for some other reason.

However, you say that SelectCity() may take a few seconds to run, so this would
normally preclude running in the EDT because the entire GUI would be blocked
while this task was performed. So you have a dilemma, you have actions which
dictate execution within the EDT, but a time constraint which dictates
otherwise.

You can get around this by using the SwingUtilities.invokeLater() method, and
move the code which adds/removes components into a Runnable which is passed to
invokeLater().