Hi Masken,
> Sorry about the dupe; I meant to post to batik-users and didn't see the > original message arrive in batik-dev. Yeah, batik-users seemed slightly more appropriate. ;-) > -Xmx512m was insufficient, but -Xmx1024m worked. Weird, I was convinced I had tested with both setting before posting... Maybe something slipped though my command-line options... :-| > Windows Task Manager reported that the program used some 980 MB of RAM. That > seems somewhat excessive to me, as the uncompressed bitmap shouldn't take > more than about 280 MB (35000 * 2000 * 32bit). Well, thing is SVG isn't just an image format description. The SVG format comprises a DOM [1], interactivity [2], scripting [3], animation [4] and a bunch of other interesting features which make a document's memory usage easily grow far beyond the canvas size referred. > Perhaps there's some optimizations that could be made to reduce memory usage. I can think of a few, although no easy ways to achieve them currently occur to me: 1. Convince the graphviz folks to optimize their SVG output. By taking a look at the generated source code, I'd say that: * A lot of properties could be inherited (through group elements, common styles such as text declared in a style sheet or in a top level element, etc.); * Elements could be referenced to instead of instantiated every time (through "symbol" or "use" elements [5], for example); * Arrows and other similar connectivity graphical elements could use markers [6] instead of paths (although I'm not sure if this would really improve memory usage); 2. When using an JSVGCanvas, switching off double buffering [7] should drop to about half the memory used by the canvas; 3. If you are sure not to use the features mentioned above, you could also consider disabling them (I'm not sure if simply suppressing the relevant Jar files [7], such as "batik-script.jar" and "js.jar", from the classpath would be sufficient); Without more digging on a potential problem on Batik's memory usage itself, I'd invite you to try further isolating the issue and/or to create a Wiki page [9] (maybe on the "How To" section) in order to start gathering a set of tricks which may help lowering Batik's memory usage (given the assumed compromises such as loss of features). Hope this helps, Helder Magalhães [1] http://www.w3.org/TR/SVG11/svgdom.html [2] http://www.w3.org/TR/SVG11/interact.html [3] http://www.w3.org/TR/SVG11/script.html [4] http://www.w3.org/TR/SVG11/animate.html [5] http://www.w3.org/TR/SVG11/struct.html [6] http://www.w3.org/TR/SVG11/painting.html#MarkerElement [7] http://xmlgraphics.apache.org/batik/javadoc/org/apache/batik/swing/gvt/AbstractJGVTComponent.html#doubleBufferedRendering [8] http://xmlgraphics.apache.org/batik/install.html#dependencyGraph [9] http://wiki.apache.org/xmlgraphics-batik/FrontPage --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
