Re: offscreen image building, general issues

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