Hi Andrea,
I just updated the patch for this issue based on your feedback. Some
additional comments inline.
On Sun, May 29, 2011 at 2:15 PM, Andrea Aime
<andrea.a...@geo-solutions.it>wrote:
> On Sun, May 29, 2011 at 7:15 PM, Justin Deoliveira <jdeol...@opengeo.org>
> wrote:
> > Right. So barring a better algorithm it would seem our choices are:
> > 1. Allow line and poly symbolizers to be label obstacles and just warn
> users
> > that in many cases depending on the data this might lead to strange
> results.
> > Or
> > 2. Limit to only point symbolizers for now... and once we do have raster
> > based collision detection enable it for line and poly
> > 3. Forgo this patch until we have raster based collision
>
> I think I would go for 1 with warnings in capital letters, maybe that would
> give incentive to other devs or user base to improve in that area.
>
Where do you think an appropriate place to do this is? I guess not in
process symbolizers since we don't want to log the message over and over.
How about when the lite feature type styles are created. We could quickly
scan the symbolizers and do the check and log the warning?
>
> >> - painting with graphic strokes with the conflict option turned on
> >> will add a lot
> >> of entries to the conflict map... I may be worrying too much, yet with
> >> small
> >> symbols we easily end up adding several thousands of entries to the
> >> conflict map...
> >
> >
> > Yeah... i thought about that as well. I will try to test an extreme case
> > and see what the impact is.
>
> Thanks!
>
So I tried a few cases with graphic strokes that involved rendering a lot of
graphics in order to try to measure the difference in terms of memory used.
Unfortunately I found it hard to measure. I tried scattering a few
System.gc() statements around with Runtime.freeMemory() statements but
couldn't really get consistent results. In general I saw a memory increase
when rendering many graphics with label obstacles on but I did not see any
sort of linear increase as the number of graphics increased.
The extreme case was rendering 250,000 line strings with a vertical line
hatch, resulting in the reserved rectangle list being populated with about
100000 rectangles. No noticeable slow down in rendering and no OOM issues or
the like but then again I did not measure precisely.
So what do you think? I could try playing with memory/gc vm parameters to
try to obtain more stable memory measurements... or perhaps try to get more
informative info out of a profiler or any other suggestions?
>
> >> - at the moment there are no tests. Now, I know the testing situation
> >> in renderer
> >> land is scary, however the new ImageAssert facility should make it
> >> possible to
> >> add a test without too much effort, just use a built in font like
> Dialog
> >> and
> >> allow for pixel difference in the assert to account for platform
> >> dependencies.
> >
> >
> > Cool will do, i have code that I have been using to test the various
> cases,
> > i will turn those into runnable tests.
>
> Nice!
>
The updated patch comes with test cases now. One question I have is what is
a good rule of thumb value for the image diff threshold? I am currently
using a value of 10... but not sure if that is to low or not.
Thanks Andrea.
> Cheers
> Andrea
>
> --
> -------------------------------------------------------
> Ing. Andrea Aime
> GeoSolutions S.A.S.
> Tech lead
>
> Via Poggio alle Viti 1187
> 55054 Massarosa (LU)
> Italy
>
> phone: +39 0584 962313
> fax: +39 0584 962313
>
> http://www.geo-solutions.it
> http://geo-solutions.blogspot.com/
> http://www.youtube.com/user/GeoSolutionsIT
> http://www.linkedin.com/in/andreaaime
> http://twitter.com/geowolf
>
> -------------------------------------------------------
>
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
------------------------------------------------------------------------------
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today.
http://p.sf.net/sfu/quest-sfdev2dev
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
