offscreen image building, general issues

I have been studying visad for a while now, mostly by digging into the
source code ;)  I have a visad based app which plots georegistered
basemaps, grid lines, and met model grid data, kind of like an 'IDV lite'.
Now I am using visad on the server side of a web app, so the user
(browser) asks for an image of some arbitrary data, and a servlet asks
visad for a BufferedImage, which I then pass to javax.imageio.ImageIO to
produce a png stream as response from the servlet, so no file is ever
created.

The problem is that the image creation is sloooooooow, up to 6 secs on my
fairly standard PC (web container is Tomcat 4.1.30).  My visad code is
really just this

1 set up, at servlet init time or for a new http session

new displayImplJ2D
add some data refs for a base map (OUTLUSAM) and some lat,lon lines
add a flatfield for grid data, domain is a Linear2DSet, 100 x 150 say

2 at request time

get some new model data, eg from a local model results file
flatfield.setSamples( the new data, no copy )
BufferedImage bi = displayImplJ2D.getImage( true )
ImageIO.write( bi, "png", servlet output stream )

I can see that the thread model for visad is complex, the threadpool of
Minnows in ActionImpl, plus a thread for the VisadCanvas.  I suspect that
all the waits/notifys and general synch issues are slowing my png
generation somewhat?  In particular, what is the purpose of the jpeg
encoder loop in DisplayRendererJ2D.getImage? (Bill??)

I have tried debugging a simple session in a good IDE but it is
bewildering.  Are there any docs on the overall architecture of visad??

What I'm really after here is a 'visad lite' for offscreen image building.
I know that I only want one thread per display, and that that thread will
change data and then ask for a redraw.  There will be no UI, no remote
references to complicate the display management.  I doubt that such a
library exists?  Would I be advised to attempt to build one?

PS: I note also that visad doesn't seem to use Swing's EventQueue.invoke*
methods, as advised for swing threading apps.   If alterations to the
display were through the EventQueue (or its wrapper calls
SwingUtilities.invoke*) maybe some of the complex threading might not be
needed.

Please don't get me wrong, I am not knocking the package, I think its
mathematical model approach is spot on, its just the execution I'm finding
tricky to adapt to my situation.  I am totally up for helping to clean up
the threading if it might be deemed necessary.

Sorry for the loooooooooong post

Stuart