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

[Etienne]

On 7/24/06, Ronan Oger <ronan at roasp.com> wrote:
>
> 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.


Hmmm.. I just rendered a 30Mb SVG (the whole of South London and half of
Surrey) using the Adobe plug-in to IE.  Took a minute or so, but this is a
massively complex file.  I guess different tools have different memory
needs.

Etienne

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
>
> _______________________________________________
> talk mailing list
> talk at openstreetmap.org
> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20060724/d98fbd25/attachment.html>