Hi Ruben:
I have a couple of suggestions; mostly around how JAI and its internal "image cache" is used.
I am really not keen on the "InMemoryCoverageLoader" code; as it represents us "fixing" a problem in the wrong manner. The trouble is we have not done the experiments to sort out what the correct manner is.
JAI makes use of a tile cache which it uses when working with raster data; and it does a pretty good job of not regenerating content it already has sorted out once. In uDig 1.1.x we did not actually use the tile cache at all; in uDig 1.2.0 I have tried storing a tile cache for each layer. While this is good in that we don't throw out our work each time we render it is bad as we do not use memory in a very wise fashion.
What we really should do is store a tile cache ...
- for each map (ie on the map blackboard?) this would allow a good balance between all the raster in use for the map; and we could "empty" the cache if the map was closed ...
- for each workbench window as Eclipse workbench service (like selection service) - which amounts to a blackboard for each eclipse window open. This would allow a larger bucket of memory to be devoted to raster use; and as we change between maps and so on JAI would be able to figure out what tiles were stale etc...
As for geotiff; there should be a fair bit that can be done. But 1st I need to ask how the image is slow?
!) is it slow when looking at the entire image zoomed out?
- If so an overlay would do wonders
- or ask JAI to create an overlay in memory when the image is 1st loaded? It would smoothly switch from the overlay to the real data when zooming in.
- or create an overlay as part of your geotiff file itself; it is the fastest way to help the performance (and no code changes)
2) is it slow when zoomed in?
- the JAI image tile cache things mentioned above should help; try different values (maybe make a preference page so users can try different values)
- go to an internal tile system in your geotiff (cannot remember what the option is called). It would prevent the disk head from running all over the place as it reads in a zoomed in "tile" of information.
- experiment with JAI title cache and geotiff internal timing (perhaps getting the two sizes to line up; or auto configuring the jai tile cache based on the tiles in your geotiff would do something?)
But yeah the number one advice here is to please chech that we are using the JAI tile cache; rather than something horrible like loading the image into memory ourself. If we have to set up the JAI tile cache and load the image into that it would be much better.
Aside: the reason we tried loading the JPEG into memory by default; is that the entire file needs to be read each time (even if we are only rendering a zoomed in part of it). In testing Silivia found that JAI tile cache was still faster than our workaround ... and allowed us to render larger jpegs.
Into the code ....
- MemoryGridCoverageMetrics - this one resolves the GeoResource into a GridCoverage (basically forcing it into memory each time. This is what the InMemoryCoverageLoader optimises. Try this out; but do not expect great performance from it...
- GridCoverageReaderRenderer this is the one to focus on ... the lines that control JAI TileCache are here
// JG: Store title cache on the layer blackboard so it can last between runs.
// Performance question: may do better to have a single larger tile cache on the map blackboard?
//
final TileCache tempCache=currentContext.getTileCache();
hints.add(new RenderingHints(JAI.KEY_TILE_CACHE,tempCache));
(As you can see my comments are consistent with this email)
The other thing to do is to go through the rendering hints (see what effect they have; and consider making a preference page for it):
// setting rendering hints
//
RenderingHints hints = new RenderingHints(new HashMap<RenderingHints.Key,Object>());
hints.add(new RenderingHints(RenderingHints.KEY_RENDERING, RenderingHints.VALUE_RENDER_SPEED));
hints.add(new RenderingHints(RenderingHints.KEY_DITHERING, RenderingHints.VALUE_DITHER_DISABLE));
hints.add(new RenderingHints(RenderingHints.KEY_ALPHA_INTERPOLATION, RenderingHints.VALUE_ALPHA_INTERPOLATION_SPEED));
hints.add(new RenderingHints(RenderingHints.KEY_COLOR_RENDERING, RenderingHints.VALUE_COLOR_RENDER_SPEED));
hints.add(new RenderingHints(RenderingHints.KEY_INTERPOLATION, RenderingHints.VALUE_INTERPOLATION_NEAREST_NEIGHBOR));
hints.add(new RenderingHints(RenderingHints.KEY_STROKE_CONTROL, RenderingHints.VALUE_STROKE_PURE));
hints.add(new RenderingHints(RenderingHints.KEY_FRACTIONALMETRICS, RenderingHints.VALUE_FRACTIONALMETRICS_OFF));
hints.add(new RenderingHints(JAI.KEY_INTERPOLATION,new InterpolationNearest()));
graphics.addRenderingHints(hints);
Finally if you scroll down you see something that is a surprise to me:
GridCoverage2D coverage = (GridCoverage2D) reader.read(group.values().toArray(new ParameterValue[0]));
...
paint.paint( graphics, coverage, rasterSymbolizer );
That is they are actually creating a grid coverage 2d (I was hoping they would use the reader; so something is up)
And that brings me to something that is a bit more fun; and has a much better chance of getting you a big speed up.
GridCoverageReaderRenderer calls the geotools GridCoverageRenderer code directly; I get the impression that the normal geotools StreamingRenderer code actually does a better job of calling GridCoverageReader than we do.
Why do we care?
Well andrea has applied a few impressive speedups to the GeoTools GridCoverageRenderer; one of which seems to be a new method.
paint.renderImage(gridCoverage, symbolizer, interpolation, background, tileSizeX, tileSizeY)
I think this method is intended when request is completely within the bounds of the raster, returning something drawable in a single step; resulting in a massive speedup. He has done a lot of work on raster performance and I am not quite clear how much of that we can benefit from (or how to do so). Perhaps a couple of questions on geotools-devel would help.
Cheers,
Jody
On 27/01/2011, at 11:51 AM, Rueben Schulz wrote:
Hello,
I have previously asked about speeding up the rendering of images in uDig. I
have tried a few things and thought I would share them and see if anyone has
any other suggestions. Note, I am using the uDig SDK 1.2.0 (geotools 2.6.x,
I think) on windows xp.
I turned off the image caching, but this actually made the jpg images load
and render slower (tiffs are not cached). As expected zoom/pan performance
was terrible as well.
The only thing I found that helped was to turn off native code in JAI (java
vm arguments -Dcom.sun.media.imageio.disableCodecLib=true). In one example
this brought the time to load and render an image down from 18s to 10s. This
had no effect on tiffs.
Does anyone have any suggestions about how I could speed up the rendering of
tiff files? For the example where it was taking 18s to load a jpg, the
equivalent tiff file is taking 35s (though a few tiles are drawn earlier).
I have a few suggestions for improving how InMemoryCoverageLoader reports
errors to users and will try to get those into a bug report this week.
Thanks,
Rueben
_______________________________________________
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.nethttp://lists.refractions.net/mailman/listinfo/udig-devel
