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
