[OpenJDK 2D-Dev] sun.java2D.pisces big memory usage (waste ?)
bourges.laurent at gmail.com
Sat Mar 30 13:01:50 UTC 2013
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
2013/3/30 Andrea Aime <andrea.aime at geo-solutions.it>
> On Fri, Mar 29, 2013 at 3:16 PM, Laurent Bourgès <
> bourges.laurent at gmail.com> wrote:
>> 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
> 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)
More information about the core-libs-dev