That may of just answered my question Andrea. We make use of GridCoverageRenderer directly - but we start by handing it the buffer to draw into. If the main advantage is the fact that it can produce the final rendered image I will have to check if we can make use of that or not.
Cheers, Jody On 17/02/2010, at 6:25 PM, Andrea Aime wrote: > Michael Bedward ha scritto: >> On 17 February 2010 11:02, Jody Garnett wrote:> >>> +1 (although I would request an IRC chat when making the transition please) >>> >> Ditto for me. > > Ok, when do you want to chat about it? I was about to write a long mail > explaining why you won't get any speedup in Swing applications and > why it's unlikely to get a significant one in SWT ones, but I guess > it's better to proceed by question and answers. > > I also suggest you have a look at the patches, the only GeoTools change > is that the GridCoverageRenderer is able to return the final rendered > image (ready to be png/jpeg encoded) instead of drawing it onto a Graphics. > It's good for GeoServer as it avoids a copy and the very bad > synchronization in graphics.drawRendereredImage (which basically makes it > impossible to draw two coverages in parallel), but in your > case, how do you leverage the fact that you can get a hold onto a > RenderedImage? > > Even for GeoServer the speedup factor for the single client case is > quite limited (and it's there because we avoid a copy from RenderedImage > to the BufferedImage that we'll encode), the big boost is there when we > have a number of concurrent clients greater or equal than then number of > CPUs. > > Cheers > Andrea > > -- > Andrea Aime > OpenGeo - http://opengeo.org > Expert service straight from the developers. ------------------------------------------------------------------------------ SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
