> The slower case is when the shapefile to be painted is > disproportionately bigger than the area to be painted. > The shapefile renderer here uses a trick, it keeps a binary > map of the pixels where anything has already been drawn, > and any feature smaller than a pixel gets compared to it, > and not drawn at all if the pixel has been touched once > already.
This was the trick we used to be comparable to other desktop apps which were working from memory. You are correct that it is a trick - I was mostly interested in this trick for line and point work as rendering large road datasets where this technique common and noticeable. I better ask on udig-dvel. > I would like to just drop the usage of the shapefile renderer > and move it to unsupported land before we go RC. I can go for moving it to unsupported; is there anything we can do to rescue the trick for point and line data in the normal streaming renderer? > PS: btw, the bitmap trick of the shapefile renderer could be > implemented in the streaming renderer too, it's just more > difficult in that streaming has to deal with features > with multiple geometries. > Anyone wants that badly? Yeah I am afraid I want it for those two uses cases; showing uDig vs other apps before that trick was sad when looking at river and road networks. That said udig 1.2 can use shapefile renderer as an unsupported module while while we think about how to use the bitmap trick. I will go ask on udig-devel and get back to you. Jody ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel