Jason Brittain schrieb:
The first time you call flush, it will send the HTTP response
headers to the client, so you would need to first set the headers before
flushing. That sounds difficult for you to do because you're writing an
image, and one of the headers would be Content-Length, which you probably
don't know until your image is generated.
Actually, Content-Length is optional as per the HTTP-1.1 spec:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
However, my take on the OP is that a better optimization strategy in
this case would be to just cache a larger image on the server rather
than generating every image on-demand. That is, when the user is moving
around in the image, the server, on the first request, would calculate
the image for a much larger portion of the map than requested and stores
it on disk in temporary storage (or in some cache area in RAM, if
feasible, after all RAM is cheap these days and 64-bit machines can have
lots of RAM). Storage of the images would not be done all at once but in
tiles. When then user then moves around in the client, the requests just
reads the tiles of the created image from disk, puts them together and
clips the borders, then compresses the image and sends it to the client.
It is possible that PNG even has some support for compressing parts of
an image so the tiles itself could be already stored in compressed
format, but it's been a while since I read the PNG spec last time. The
same could be done for zooming by storing images in a pyramidal
structure, like it is done in pattern recognition. While the user is
moving, a background thread associated with the client could try to
anticipate where the user is likely to be moving to and calculate the
given tiles in advance. Actually, this sounds like an interesting
project for several Ph.D. theses...
Markus
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
