see below... ------------------------------------------------------- Ing. Simone Giannecchini GeoSolutions S.A.S. Owner - Software Engineer Via Carignoni 51 55041 Camaiore (LU) Italy
phone: +39 0584983027 fax: +39 0584983027 mob: +39 333 8128928 http://www.geo-solutions.it http://simboss.blogspot.com/ http://www.linkedin.com/in/simonegiannecchini ------------------------------------------------------- On Wed, May 27, 2009 at 10:36 PM, Andrea Aime <[email protected]> wrote: > Simone Giannecchini ha scritto: >> I am a bit worried about trying to kill the rendering loop when native >> libs for doing I/O on coverages and ad a Java2D call to >> drawRenderedImage with a deferred loaded raster are involved. >> We might be trying to kill a java thread while it is inside native >> code doing I/O. Seeing a JVM crash would be not that unusual. Have you >> thought about this? > > I'm not playing with threads, the ability to kill a thread > is deprecated anyways. But I'm disposition the Graphics2D > while rendering is going. cool > The JAI native code might be using it, so that might > cause issues. I'll double check. > Can you suggest a better way to stop coverage rendering > mid-flight? In the end what the coverage renderer > does, is to setup a JAI processing chain, and the chain > is set in motion by a single, atomic call to the > graphic context. How do you stop it? Though call. The variables are many it is not easy to come up with one solutions that would fit all. In principle killing the graphics should work, since that would mean killing the sink of the jain, not the source (the native code itself). As you know, JAI chains does not have themselves a stop button. We could work that around by wrapping operations, but it's neither easy nor simple. Moreover your approach would work (raster-wise) only if deferred loading is allowed. In case, like for gdal, we avoid the ImageRead path and we down the simple read path, you'd still might suffere from ethernal loading times in case you have to load an enormous raster and then rescale (just think about a large jp2k without many pyramid levels, which you want to rescale to a small area. Add to this that it might be badly tiled and you are f***d :-) ). I guess that fighting against long running requests in a really robust (raster-wise) would force us to push loading into an external process which we can stop at our covenience without problems. For the time being we can just try your approach and I can try to thinkabout something different, but I doubt I can find anything better than what you come up with. Simone. > > Cheers > Andrea > > -- > Andrea Aime > OpenGeo - http://opengeo.org > Expert service straight from the developers. > > ------------------------------------------------------------------------------ > Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT > is a gathering of tech-side developers & brand creativity professionals. Meet > the minds behind Google Creative Lab, Visual Complexity, Processing, & > iPhoneDevCamp as they present alongside digital heavyweights like Barbarian > Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com > _______________________________________________ > Geoserver-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/geoserver-devel > ------------------------------------------------------------------------------ Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp as they present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
