----- Original Message ----- From: "Thomas DeWeese" <[EMAIL PROTECTED]>
To: "Batik Users" <batik-users@xml.apache.org>
Sent: Tuesday, February 15, 2005 2:31 PM
Subject: Re: how to dispose JSVGCanvas?
Hi Thomas,
Thanks for your help, again. Some things are clearer to me, now.
Lukasz Matuszczak wrote:
I am not sure what is a proper way to close JSVGCanvas, and all its inner objects and threads. Do I have to use "stopProcessing" method or is calling of "dispose" method sufficient?.
Dispose should be enough (it will call stopProcessing if something is going on).
Ok, so is calling "dispose" call always enough? or do I have to call any other methods, for example unregister all listeners, flush caches, or something?
I want to free all image caches too. Does method flushImageCache() from JSVGComponent fulfil my needs or do I need to call flush() from JGVTComponent?
'flushImageCache' is different from 'flush' on the JGVTComponent. I should have dispose call flush() (thanks for bringing this to my attention).
The Image cache uses SoftReferences so they will clear as soon as there is memory pressure.
Yes, I understand it, but i would like to clear the image cache while disposing a JSVGCanvas, because I know i will never use this. As far as I understand a JSVGCanvas object holds strong references to SoftReferences in a cache object (indirectly) so when I lose the last reference to JSVGCanvas (after disposing it) I will also lose references to SoftReference objects.
Therefore the image cache objects will become available for garbage collecting, even if there is no memory pressure (because they won't be even softly reachable). Am i missing something? I hope that Image Cache is not static and is connected with concrete document.
Does method "flushImageCache()" clear image cache, even if there is no memory pressure?
Calling 'flush' will clear cached rendered tiles for static documents (there shouldn't be anything for dynamic documents). This is a combined soft/hard reference cache (limited to ~4MB).
I am also curious if it is safe to call above mentioned methods before my JSVGCanvas is fully started (ie before gvtBuildCompleted, gvtRenderingCompleted methods are called).
Yes it should be.
I think that is important because i occassionally ran into an exception (in 1.5.1 release):
java.lang.NullPointerException at org.apache.batik.swing.svg.JSVGComponent.stopThenRun(JSVGComponent.java:606)
I think you can only get this if you call 'dispose' out of the swing thread.
Thanks for this hint, I will look through my code again.
I think that the whole JSVGCanvas lifecycle is a bit complicated.
Well, any multi-threaded object's lifecycle tends to be a bit complex.
Yes I agree, and I don't consider it as a disadvantage of JSVGCanvas.
I haven't found any detailed description of it,
What sort of description would be useful? Can you point me to an example of what you would be interested in?
I think that more detailed description of methods in Javadoc would be useful. For example "dispose" method has no comment at all.
I would like also to see examples of typical usage of different types of listeners. Sometimes I am little confused which listener and which method of it is a proper place to put my code in, so I think that description in http://xml.apache.org/batik/svgcanvas.html Event Handling section could be extended.
In general documentation is a problem of almost all free projects, but to understand the complexity and great variety of functionality of batik project, new tutorials and examples would be very helpful in the future. Don't you think?
so it is not obvious for me which methods may be called asynchronously on JSVGCanvas and when they may be called.
_NO_ method may be called asynchronously on JSVGCanvas. Like all swing components you can only safely interact with them in the swing event thread.
My mistake. I missed that.
I have also a short question about listeners related to JSVGCanvas object.Is it true that all methods in listeners registered on JSVGCanvas events (for example in GVTTreeRendererListeners) are invoked from AWT event dispatching thread? I discovered it recently and I am not sure if it is an intentional behaviour.
Yes, it is intentional it should only call listeners registered on it from the Swing thread.
Thanks.
Best Regards
Lukasz
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
