NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
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
visad archives: