On Sat, Mar 30, 2013 at 2:01 PM, Laurent Bourgès
wrote:
> - clipping issues (dasher, stroker) and spatial resolution (no cpu/memory
> waste)
>
I see, yes. Indeed in the GeoServer code we already work around some of
those issues by
clipping the geometries read from the database to the graphics2d v
Andrea,
thanks for these estimates / stats.
I think such use case could benefit a lot from my patch (low memory
footprint) but thread-safe cached / reused arrays/ LineIteratorData /
StrokerData / DasherData.
As I said to Jim, there are two sort of problems:
- memory handling (growable arrays) ha
Jim,
There are finally only few growable arrays (edges, curves, rowAARLE) and
now I have a working Pisces code (J2DBench pass OK) that performs better
than current (2x - 3x faster on dasher or big shapes) using only few
megabytes (Xmx32m) ...
Moreover, these arrays could be created once per threa
Jim,
thanks for your interesting feedback.
2013/3/30 Jim Graham
> J2DBench does not have a regression test mode unfortunately.
>
> Clipping in the stroker and dasher is doable, but it is complicated by the
> fact that stroking adds decorations that are not always easy to account
> for. Round j
On Fri, Mar 29, 2013 at 3:16 PM, Laurent Bourgès
wrote:
> Andrea,
>
> It could be very interesting if you could provide some concrete example
> about your map server: typical image height / width, shape complexity
> (number, size, path sizes ...).
>
It's all over the place. Image size: from 256x2
