xmlgraphics-batik-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lukasz Matuszczak" <l.matuszc...@atrem.pl>
Subject Re: how to dispose JSVGCanvas?
Date Tue, 15 Feb 2005 15:12:48 GMT

----- Original Message ----- 
From: "Thomas DeWeese" <Thomas.DeWeese@Kodak.com>
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 

>    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 
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.

Best Regards

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

View raw message