Hi Emzic,

emzic <[EMAIL PROTECTED]> wrote on 07/25/2008 05:29:40 AM:

> i have extended SVGAbstractTranscoder in order to implement my own
> transcoder that creates BufferedImages.
> 
> this transcoder executes the GvtBuilder.build() over and over again, 
since
> the SVGDocument changes. (for example, if the style-attributes changes 
the
> BufferedImage needs to be updated.) 
> 
> now i noticed a memory-leak when doing this. it seems that the
> GvtBuilder.build() creates lots of EventListeners on the DOMNodes. which
> don't seem to be garbage collected when you rerasterize the document.
> i also noticed that this memory leak can be avoided when you call
> 
> BridgeContext.unbind( document );
> BridgeContext.dispose();
> 
> after the rasterization.
> 
> now my question is, is that the right way to do it?

   You shouldn't need the unbind & dispose calls if you
set the BridgeContext to 'STATIC'.  However read on...

> or what is the suggested way of rerasterizing a changing 
> SVGDocument over and over again without memory leaks and 
> with the highest performance?

   This is effectively what the Canvas does for dynamic
SVG documents.  It loads an SVG document and then when the
document is changed it re-renders just the part of the document
that changed and displays it.  This is the highest 
performance way to render a changing document.

   This is why the Bridge registers those listeners so
it can track changes in the document and update the 
rendering (GVT tree).

   The simplest way to achieve this would be to actually
use the JSVGCanvas and listen for 'updateCompleted' and
'gvtRenderingCompleted' events on the canvas and use them
to get the 'offscreen' buffered image that the canvas 
maintains.

   This will probably work well unless the size of your
document changes often (the canvas's behavior is to only
render the part of the document that is visible).  If you
want to you can potentially manage your own 'dynamic 
document', the primary part of this is creating the
'UpdateManager', adding your UpdateManagerListener,
and calling UpdateManager.manageUpdates(ImageRenderer).

Reply via email to