xmlgraphics-batik-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas DeWeese <Thomas.DeWe...@Kodak.com>
Subject Re: SVGImageElement bug - memory leak
Date Wed, 23 Jun 2004 20:03:42 GMT
Hi Andres,

    So I need some more information because what you list is
correct according to design and should still allow for GC.

    The real question is who is referencing the ForwardEventListener?
The only references to it should be from the Bridge Context via
soft references - which will allow everything to go to GC if
nothing else references it.

    I was wondering if you might be keeping the image elements
around (although disconnected from the document - perhaps
even moved to a defs section).

    Also sample content would of course help.

Andres Toussaint wrote:

> Hi:
> Greetings to all the Batik Community.
> I wanted to point out this Bug again, for it to be salvaged from oblivion.
> Regards,
> Andres
>> Hello all:
>> I want to report what appears to be a bug in the SVGImageElementBridge 
>> implementation. I have tried it with Batik release 1.5 and 1.5.1.
>> In a dynamic JSVGCanvas, on the UpdateManager thread, when i remove a 
>> SVGOMImageElement (that represents an embedded SVG image, i.e. 
>> CompositeGraphicsNode) using
>> AbstractParentNode.removeChild(SVGOMElement);
>> The removed SVGOMImageElement cannot be garbage collected because it 
>> is still referenced by an instance of 
>> SVGImageElementBridge.ForwardEventListener (it is listed as imgElement 
>> of SVGImageElementBridge... by my profiler software)
>> I have tried the same method for SVGOMImageElement loading a embedded 
>> PNG image (i.e. RasterImageNode) and the node does get released of all 
>> its references and it is garbage collected.
>> Also, I have tried it with SVG elements constructed within the app 
>> ("rect", "g", etc....) and they also are released completly, and 
>> disposed of properly. The only problem I found is with SVGImageElement 
>> loading a external SVG images (i.e CompositeGraphicsNode).
>> This situation generates a considerable Memory Leak if you want to 
>> add-remove dynamically external SVG images into your JSVGCanvas 
>> document, since every remove will leave the removed SVGOMImageElement 
>> lingering there without being released for disposal, and at some point 
>> it saturates the JVM allocated memory and crashes the application.
>> If anybody has found a solution to this issue, i would appreciate some 
>> help.
>> Andres.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: batik-users-help@xml.apache.org

To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org

View raw message