[Tilesathome] less inkscape calls in _unstable

[Matthias Julius]

"David Lynch" <djlynch at gmail.com> writes:

> I've run Inkscape a few times with that tileset and a couple others and found:
>  - When Inkscape starts, there is a substantial amount of time elapsed
> and memory allocated before the output file is created. The length of
> time and amount of memory used are roughly proportional to the size of
> the SVG file, and don't seem to change based on the output parameters.
>  - After the output file is created, the amount of memory and time
> used varies with the complexity and size of the area being output.
> Complexity changes things more than more than size, and memory changes
> more than time.
>
> Given those observations, my assumption is that it is loading and
> parsing the entire contents of the SVG, but that the rendering isn't
> of the full image.
>
> This morning, I got a usage of 1.2 GB on a 4096x4096 render of the z17
> data (the only file I kept) and 1.4 GB when re-running the 8192x8192
> render. I don't know what accounts for a full gigabyte of difference
> from the previous attempt; I'm fairly sure I didn't misread either set
> of numbers, but that might be the case.
>
> Overall, eliminating as much of the striped rendering as possible does
> seem to be the way to go, given the overhead in starting Inkscape. I'm
> playing the devil's advocate somewhat, since the example I happened to
> get is probably close to the upper bound for complexity. How to deal
> with those sorts of cases falls back on the old programmer's dilemma
> of speed versus memory efficiency.

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.

Matthias