Harm Cuppens wrote:

Hi all,

I'm experiencing java.lang.OutOfMemoryError when trying to load a big
svg file (a whopping 5.35MB).
I have the latest CVS version of Batik.

The document i'm loading is static, so I've been trying to delete the
dom elements as soon as they have been converted to their corresponding
gvt equivalents (in GVTBuilder) in the hope to free up some memory.
Unfortunately I haven't been successful to get rid of the outofmemory
error. This process is also terribly slow because each removal of a node
checks if the node is a child of the parent we wish to remove it from
and the parent contains 40.000 nodes. But that is not batik's fault but
the way DOM works.


It sounds like something funny is going on here. As long as you are deleting nodes from
start to finish the removal time should be quite good. You might want to check that you delete
TextNodes between the elements (I'm guessing that you have an equal number of Element nodes
and Text nodes in the DOM as generally your element nodes have whitespace between them
(like a newline + indenting) - if you don't remove these as well as the real elements it could
get slow to find the last few elements. Also this should help memory use quite a bit.


   Can you tell if the nodes you are removing are getting GC'd?
   What are the nodes, shapes, text, use?

Is there a way to cope with this other than increasing the java heap
size? It loads fine in the Adobe SVG plugin.


It is likely the Adobe plugin is using more than the default 32MB Java heap.




--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to