Hi Stuart,
I doubt that VisAD's Thread model is the source of your
performance problems. Jeff McWhirter and Don Murray of
Unidata have been doing great work on profiling and
improving VisAD performance, and as far as I know they
have never found performance problems related to the
Thread model.
One thing that is slow is starting up a new VisAD
application, which requires loading lots of classes.
Ditto for starting any application that uses Java3D.
Displaying large data objects can be slow, as they
require lots more memory for the logic that transforms
them into graphics.
I have no experience with Servlets, so perhaps some
other developers can give you better advice. You might
try some profiling on your application.
As to your specific questions:
You can learn about the VisAD architecture in the
Developer's Guide, and the display architecture in
the DataRenderer tutorial. Also in other tutorials.
For very general overviews, see the on-line copies of
various magazine articles.
Building a 'VisAD lite' library would be an enormous
task, if it supports the data and display models. You
won't really save yourself much work by dropping UI,
remote references, and threading.
VisAD does make extensive use of Swing support for
asynchronous invocation of Runnables, but not via the
EventQueue class. See visad.util.Util.invoke() (and
others). VisAD creates lots of Threads because it
enables users to create very complex applications with
lots of displays and user interface events. We gave the
system its own Thread pool because early on we weren't
sure if every Java implementation would include a
Thread pool (we started the Java VisAD design in January
1996, when JDK 1.0 was just coming out of beta).
And as to "what is the purpose of the jpeg encoder loop
in DisplayRendererJ2D.getImage?", you may have noticed
the comment in that code:
// this is a total hack; works for reasons not understood
The system allows you to define and use your own extension
of the DisplayRendererJ2D class, where you can experiment
with different implementations of getImage(). Good luck.
Bill
On Wed, 20 Apr 2005, Stuart Maclean wrote:
> 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
>
>
>
