Hi Stuart,
I was trying a similar thing using JSP a while ago, so your comments
prompted me to take another look.
I found that the time taken depended on the size of the image being
created. One timing test I did looked like this:
2000x2000 pixel image = 16 seconds
1000x1000 = 8 seconds
500x500 = 4 seconds
250x250 = 2
125x125 = 1-2
(times varied of course, but this was the type of trend).
I was using the JSP code below. For the fun of it, I then tried omiting
the ImageIO.write, and found in one case that it reduced the time by
over 50% (ie the 2000x2000 image took 7 seconds to create, including
querying a dataset on a server, whereas it had taken 16 seconds in total
before to also do the ImageIO.write). The conclusion I draw from this is
that VisAD is responsible for less than half the delay in creating and
writing the image and that Java is doing the rest.
JSP code:
<%@ page
import="java.util.*,visad.*,visad.java2d.DisplayImplJ2D,test.ModelDisplay"
%>
<%
response.setContentType("image/png");
java.io.OutputStream os = response.getOutputStream();
ModelDisplay modelDisplay = new ModelDisplay();
DisplayImpl display = modelDisplay.getDisplay();
java.awt.image.BufferedImage buffImage = display.getImage(true);
javax.imageio.ImageIO.write(buffImage, "png", os);
os.close();
%>
BTW, to omit the ImageIO.write, I found that I needed to write something
to the output stream, so did the following:
// response.setContentType("image/png");
Byte b = Byte.valueOf("1");
os.write(b.byteValue());
(otherwise an error message would be produced)
Hope this helps,
James
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
--
James Kelly Meteorological Systems Section
Phone: 61-3-9669-4724 Fax: 61-3-9669-4128 Email: J.Kelly@xxxxxxxxxx
