Re: OutOfMemoryError on graphviz-generated image

[Helder Magalhães <he...@gmail.com>]

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: batik-dev-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-dev-help@xmlgraphics.apache.org