[Tilesathome] less inkscape calls in _unstable

[Jiri Klement]

Memory shouldn't be a problem for Batik. I have memory limit for java
set to 1500MB and I have never encountered a tile I couldn't render.

But somebody did a benchmark which showed that batik is much slower
than inkscape when tile is rendered in one go. It looked like it's
even slower than when the tile is rendered in stripes by batik.

Actually I did some profiling of batik and the results where quite
suprising. About 80% of time is spent in method, which copy rendered
element into resulting image. So it's possible that rendering big tile
will be actually slower than rendering many small tiles.

On Wed, Sep 24, 2008 at 8:49 PM, Matthias Julius <lists at julius-net.net> wrote:
> "David Lynch" <djlynch at gmail.com> writes:
>
>>> Maybe the way to go is to get rid of striped rendering alltogether and
>>> have users set their MaxTilesetComplexity appropriately if their
>>> Inkscape is eating too much memory.  As long as there are a couple of
>>> power-renderers that can handle those tiles we are probably fine.
>>>
>>> We can then have the client tell the server its MaxTilesetComplexity
>>> so the server won't hand out jobs the client will return anyway.
>>>
>>> This should ensure the best turn-around for rendering.
>>
>> It seems like a good solution. I might recommend going a bit further
>> and giving MaxTilesetComplexity a value (somewhere around 8-10
>> million?) in the default configuration file and letting people opt in
>> to the biggest files, instead of the current unlimited value.
>
> This seams sensible.  That's what I'll do if nobody objects.
>
> It would still be good to hear from a Batik user.
>
> Matthias
>
> _______________________________________________
> Tilesathome mailing list
> Tilesathome at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/tilesathome
>