I didn't know that about the java heap. Wow, that's small. It would explain alot. I was just living with it. Silly. I'm gonna increase it today.
Thomas DeWeese wrote:
John Greene wrote:
When I'm displaying (on a JSVGCanvas) an image with 400 or so quadcurves I often get outofmemory errors (I can render
64,000 lines no prob).
Just to eliminate or confirm a possibility, does batik render quadcurves in an especially memory-consumptive way?
Hi John,
We just pass the quadcurves to the JDK for rendering. We do need to do some complex operations on them (like stroking if you use stroking) to calculate bounds etc.
Can you provide sample content? It seems to me like we have delt with
much larger/complex files than 400 quadcurves but I guess I don't know for
certain. Also are you aware that the default heap for Java is ~32-64MB -
which isn't a lot these days (although 400 quadcurves should fit :).
My suspicion is that you are using features like group opacity/filters etc
that use lots of memory - it is not the quad curves.
> Does it reduce them to massive polylines?
As I said this is done by the JDK so I don't really know, but every quadcurve renderer I am aware of works this way (adaptive subdivision to screen res).
> Are there a bunch of path-iterators hanging around past their > usefulness?
I don't believe so (just about the only place we create path iterators is
for markers).
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
