The JSVGComponent.loadSVGDocument creates a new Thread to load the specified document. If too many JSVGComponents are placed on the same page and initialized in a loop, this causes creation of too many threads and eventually leads to OutOfMemory error. It would be nice to have a thread pool of configurable size (static for the JSVGComponent class).
(In reply to comment #0) > The JSVGComponent.loadSVGDocument creates a new Thread to load the specified > document. If too many JSVGComponents are placed on the same page and initialized > in a loop, this causes creation of too many threads and eventually leads to > OutOfMemory error. It would be nice to have a thread pool of configurable size > (static for the JSVGComponent class). I doubt that the thread pool would help much. In all likelyhood you are just running out of memory. If you haven't already I would suggest increasing the default memory allocation in the JDK. Also since we restrict ourself to JDK 1.3 we would either have the create our own thread pool or add a dependency on another java library (I suppose Apache Avalon or the like must have one). Since I'm fairly convinced that the number of threads is not the real issue I am reluctant to do this. If you can provide good evidence that the problem is the threads rather than the memory needed to display lots of SVG images feel free to reopen.
Well, i don't have evidence that all the threads lead to OOM error. But, when you have 500 components in a scroll pane, it's not a good idea to have 500 threads running in any case... What's wrong with a dependency on Apache Excalibur that have thread pool implementation (i'll need to see if it's good for this specific scenario - see bug 40394). You already have js.jar, pdf-transcoder.jar, xerces and xml-apis. It's not the first dependency you'd introduce.
(In reply to comment #2) > Well, i don't have evidence that all the threads lead to OOM error. But, when > you have 500 components in a scroll pane, it's not a good idea to have 500 > threads running in any case... Isn't it a bad idea to have 500 components in the scroll pane when the user's going to see, what like 20? The swing components are designed to populate the view on demand. I would suggest using this feature. > What's wrong with a dependency on Apache Excalibur that have > thread pool implementation (i'll need to see if it's good > for this specific scenario - see bug 40394). I don't have a hard rule against dependencies it's a matter of balencing the provided functionality vs the additional synchronization issues it cause everyone (users of Batik now need Batik's version of that library to match the version that other tools may be using just as an example). > You already have js.jar, pdf-transcoder.jar, xerces and > xml-apis. It's not the first dependency you'd > introduce. The only one above that is a hard dependency is xml-apis which is kind of required for an XML implementation. js.jar & pdf-transcoder.jar are only required if you are using their functionality. The Xerces dependency is configurable (simply requires a SAX 2 interface, and has recently moved to JAXP).