[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [udig-devel] Raster Performance and GeoTools grid coverage rendering
|
On Sun, Jan 30, 2011 at 1:19 PM, Jody Garnett <jody.garnett@xxxxxxxxx> wrote:
> Okay manage to ask Andrea a few questions.
> We can safely ignore GridCoveargeRenderer.renderImage - the method is useful
> inside geoserver as they can encode the result and avoid Java2D; since we
> are going to screen we may as well hit Java2D early and keep going.
> The use of gridcoverage looks suspect; and we should dive into the normal
> streaming renderer to see how to call gridcoveragerenderer more properly. My
> personal expectation is that we should stuff the reader into the call to
> GridCoverageRenderer and let it sort it out?
Generally speaking you should get good performance by:
- building layers out of coverage readers (the streaming renderer code
will setup
a read that picks the right area and the right overview level)
- keep the readers open in a cache of sorts so that you don't re-read
the headers at each access
- eventually call ImageIO.setUseCache(true); to also have the imageio readers
use the file cache (mind, that and the above migth result in having too many
open files at once if you're trying to deal with a large mosaic)
Hope this helps
Cheers
Andrea
> Jody
> On 27/01/2011, at 1:07 PM, Jody Garnett wrote:
>
> 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.net
> http://lists.refractions.net/mailman/listinfo/udig-devel
>
>
>
--
Ing. Andrea Aime
Technical Lead
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584962313
fax: +39 0584962313
http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf
-----------------------------------------------------
