[OSM-talk] SVG to PNG without burning lots of memory

[Ronan Oger]

Simon,

Regarding the bloat, you are overlooking that the XML is a model, not a 
result. 

7MB of XMLdescription is much bigger in ram due to the model it calculates.

SVG is an image modelling language. The full canvas is generated in ram, and 
that can take a lot of space if the image is actually complex.

A 7MB SVG image model is pretty big, probably too big for your 512MB image, 
especially if you have complex shapes with lots of vertices. The rasterizer 
DOM modeller probably consume 20-50MB *before* loading the image. 

Have you checked that you don't have *other* processes playing with your ram? 
It could be that of the 512M of ram, 400M are taken up by the OS and other 
bits...

I suggest you do some testing starting with 100K images and working your way 
up, seeing if you can identify where the problem occurs.

You're right that gzipping won't help the ram footprint, my goof. I got ahead 
of my brain there.

You might take a look at using certain constructs instead of others. For 
example, for every shape, there is an entry in the shadow tree of the 
renderer to decide whether there is an overlap. Sometimes it is better to use 
one kind of shape rather than another (varies with each renderer, of course).

Good luck,

Ronan

On Monday 24 July 2006 21:10, Simon Hewison wrote:
> Ronan Oger wrote:
> > Here are some more SVG to PNG options:
> >
> > 1) batik rasteriser
> > 2) ksvgtopng on (kde)
> >
> > Regarding your 7MB of xml bloat... You may consider (1) optimizing your
> > LOD (level of detail) to best match the expected screen size before
> > generating the svg image. (2) optimizing the SVG output for the smallest
> > possible content (3) gzipping the svg.
> >
> > If you want to send me a sample of the output, I can take a look at it
> > and offer you some hints.
> >
> > Your big problem is that SVG needs the entire document modelled in ram as
> > a canvas before it can proceed and dump the contents to screen.
> > Crazy-high resolution in the data causes crazy-high memory usage.
>
> Okay, even if SVG is using a Document Object Model, then 7MB of XML
> bloat should become less than 7MB in RAM. That's no big deal. I've got
> many orders of magnitude more than that on my desktop machine. Gzipping
> the SVG will NOT help the memory footprint when the renderer models the
> entire lot into it's in-memory structures, since the first thing it will
> do is decompress it.
>
> As for the memory footprint for a 32 bit uncompressed bitmap for it to
> render into, that's still not a huge amount of memory these days. It was
> a decade and half ago when laser printers had the same problem. 4 bytes
> per pixel x 2048 x 1538 resolution is still only just a bit over 12MB..
> So why can't I take my 7MB of (xml padded) data into RAM, and turn it
> into a 12MB canvas without burning over 250MB of RAM?
>
> It seems that software authors have forgotten the concept of efficient
> coding these days. If I had the time, I'd sit down and write an
> efficient SVG renderer. Sadly, I haven't the time.

-- 
Ronan Oger
Director
RO IT Systems GmbH
	...Building Web2.0 with SVG since 2001

http://www.roitsystems.com