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) has to be smart (auto - tune) - clipping issues (dasher, stroker) and spatial resolution (no cpu/memory waste) 2013/3/30 Andrea Aime <andrea.a...@geo-solutions.it> > On Fri, Mar 29, 2013 at 3:16 PM, Laurent Bourgès < > bourges.laur...@gmail.com> 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 256x256 to 10000x10000, number > of shapes, from a few hundreds to a few millions, path sizes, from say 10 > points > to thousands (the code already makes sure there are no two consequent > points sitting in the same pixel before trying to draw them), > stroke wise it can be simple or using dasharrays. > > >> >> Ideally if you could write a test class (sample) computing a single image >> it would be very helpful for me to compare my patched pisces vs current one. >> > > I don't have anything ready, the existing code loads data from spatial > database, sets up styles from XML descriptions, turns each spatial db > geomety in java shapes > and so on. But I guess I could concoct something close enough. > I'm writing some code to gather statistics about the shapes that are > actually painted (scrolling over the path iterators) and then I'll try to > make a randomized > shape painter that gets close to those stats. > Great news ! I am waiting your test code to perform few benchmarks. I am using J2DBench but it does not perform such complex drawing (complex shapes ...) or multi threading tests (parallel drawings on buffered images) Laurent
