Developers Corner: Improvements to the rendering engine on upcoming GeoServer 2.1/GeoTools 2.7

In this installment we are going to look into the rendering speed improvements featured in the the upcoming GeoServer 2.1/GeoTools 2.7.0 release.

We recently talked about a very significant one already: raster reprojection performance has skyrocketed, providing an overall speedup factor of four to six on the overall reprojected WMS request chain (if you want to know about the pure GeoTools reprojection operation speedup, it’s more alike a hundred times faster).

What you might not know is that the above is coupled by another speedup that we made for the WMS shootout 2010: the “direct rendering path”, which makes GeoServer into a proper image server.
What’s the difference between a generic WMS server and a image server you might wonder? Well, a generic image server takes all the data sources and paints them on top of a rendering surface, applying styling as it goes. The rendering surface is commonly a blank RBG(A) image in memory on which features and rasters and combined.
Now, the thing is, if you are starting with a raster, you already have an image: there is no need to go through the generic rendering machinery, JAI can do all the required transformations directly and more efficiently than Java2D.
GeoServer 2.1 calls the above the “direct rendering path”, and it’s activated every time a WMS request contains a single raster layer: this gives another four-fold speedup at high load, and 20/50% speedup at the single user level.

The goodies embedded in GeoServer 2.1 do not stop here, significant improvements have been done in vector data rendering as well:

  • The renderer fetches vector data and renders it in two separate threads, allowing to distribute the request load among two cores
  • Large polygons are isolines are now clipped to the rendering area before being passed down to the Java2D rasterizer, greatly improving the performance on larger isoline layers and avoiding issues with one of the oldest unresolved java2D bugs which might bring a server to his knees when a large isoline or polygon is painted with a dash array and the user starts zooming in a lot (so that only a small part of the geometry is in the viewing area)
  • A special map is setup to track of very small geometries, this helps when rendering a very large amount of small objects at a low zoom level as it avoids painting over and over in the same pixel (this trick was available on 2.0.x as well, but only on shapefiles)
  • Shapefile indexing of very large data sets has improved significantly, making for smaller, but at the same time more selective, spatial index files. If you are upgrading from 2.0.x you should remove all your .qix files and let GeoServer rebuild them to take advantage of the improvements

We hope to setup a benchmarking session allowing us to get fresh comparisons between 2.0.2 and 2.1.0 once the release is done, possibly using the WMS 2010 shootout workload: stay tuned for more details on this one.

Of course there is still a lot that can be done to improve rendering performance. Do you have a specific case that you want to be improved? Interested? Let us know!

The GeoSolutions team