Maxim Shemanarev wrote:
> Well, I wrote this example mostly to check the performance, because I had some
> doubts in it. So, as just yet another proof of concept. This is why the storage
> is so poor. Actually, path_storage is too primitive for these kind of tasks.
> For real tasks there are two ways. First, and the easiest way is to take some
> XML DOM library (Xerces), load the SVG file and traverse it, parsing paths, etc
> on the fly when rendering. It's very slow and has terrible memory overhead. For
> example, 30MB SVG file takes more than 200MB in memory as a DOM structure (I
> tested it with Xerces). The Adobe SVG Viewer ate 450MB of memory and started
> swapping as hell, so, I had to kill the task.
> AGG viewer couldn't display many things like text, but it displayed the main
> things. It takes about 16 seconds to parse the file and 1.6 sec to display it.
> So, another approach is to use a simple SAX parser, converting data into a
> binary form and accumulating it in memory, so that, you could keep a compact
> binary serialized structure as the exact reflection of XML DOM. It'll be a
> binary pseudo-DOM with drawing commands, references, etc. As the practice
> shows, 30MB SVG file takes less than 10MB in memory. Besides, I'll be much
> faster, I suppose it should be as fast as the existing path_storage. But it's a
> separate, nontrivial task. If you use a SAX parser, you will have to take care
> of DTD, CSS and possibly XSLT.
You push SVG to the limits, don't you? :-)
Most SVG files are way under 1MB, but of course, files generated by data
(like database, GIS or others) can be quite heavy.
I believe that for making a serious SVG viewer, DOM is the way to go, to
allow scripting (which accesses to the DOM tree).
If animation & interaction is dropped, I suppose SAX is a good way to
go. Perhaps a good viewer would switch to either one, depending on user
preferences/detection of some features/size of the file.
Jerry Evans wrote:
> I should qualify my comments by saying that I was only interested in
> subset. The entire spec is huge, complicated and judging by the
> existing viewers, damned hard to get right (animation/filters/...)
> How much of the spec do you want to handle ?
Note there are SVG Tiny and SVG Basic (two profiles for SVG Mobile
<http://www.w3.org/TR/SVGMobile/>) which define subsets of SVG, with
simplier requirements, to allow easy implementation on low end hardwares
(mobile phones, PDAs, etc.).
They can be a good start for implementation.
-- (near) Paris -- France
-- Professional programmer and amateur artist
-- -- -- -- -- -- -- -- -- -- -- --