Hi, I was thinking about the idea of having a custom rendering path for the raster images.
Having a separate path would sure provide a speedup, but I was thinking that we can probably get a more general speedup by integrating it into the main chain instead. The idea is as follows: - if the map context contains a coverage as the first layer, remove it from the context and render it with the fast path. We end up with a RenderedImage, which is also the final result if we don't need to draw anything else. - if the map context contains more layers, or if we need to apply a layout, we take the RenderedImage, turn it into a BufferedImage by creating a writable raster out of the RendereredImage (just like it's done in the workaround for the JPEG native image writer not working with translated images), and from there we go and do business as usual This should still provide a speedup, but it is of more general application and should speed up also the common case of multilayer map with a raster layer in the background What do you think, would it work? Cheers Andrea -- Andrea Aime OpenGeo - http://opengeo.org Expert service straight from the developers. ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
