I shut down my animation timer and I no longer see the exception. I still have to reload twice to get the document to appear. I'm doing:
animationTimer_.shutdown(); // and waits for thread to stop canvas_.setSVGDocument(null); // create a new document canvas_.setSVGDocument(newDocument);
Do you see any problem with that?
Yes (and this is something I've been meaning to fix but haven't). When you call setSVGDocument(null), it start the processes of 'shutting down' the current document (canceling repaints, stopping scripts etc), Since this could take a while I call a number of quick methods to tell everything to shut down and register a number of event listeners and just return.
When the event listeners are called (because the document is shut down) I call 'install document' with the document to be installed.
The above code will in most cases register these listeners twice - once for the 'install' of the null document, once for the install of 'newDocument'. This probably isn't fatal but as you seem to have discovered don't have a strong notion of which document (null or new) will in the end be installed.
I would suggest skipping the setSVGDocument(null).
Now that this is likely a 'real problem' as opposed to a theoretical one I will bump the priority on fixing this issue.
Thanks, Denis
----- Original Message ----- From: "Thomas DeWeese" <[EMAIL PROTECTED]>
To: "Batik Users" <[EMAIL PROTECTED]>
Sent: Wednesday, October 01, 2003 11:01 AM
Subject: Re: JSVGComponent dynamic DOM update, invokeAndWait threading issue
Denis Bohm wrote:
Hi Thomas,
My animation timer doesn't cache anything (including the runnable
queue) -
it get's it from the canvas each time an animation is activated. So it appears that during a reload a canvas can have a runnable queue still around - but one that has exited? I don't think I understand which
canvas
objects are shutdown, recreated, etc and the timing of all that. I'll
take
a look at the Batik source in those areas...
Yes during document loading there is a time where the UpdateManager
from
the previous document is still available but shut down, and the
UpdateManager
from the new document has yet to be installed.
The UpdateManager does have a 'isRunning()' member, however I would
strongly
suggest shutting down your animation engine while a document is being
loaded.
From the time you call setDocument/URI to the completion of the first GVT
rendering
you should really just leave the canvas alone! :)
Thanks, Denis
----- Original Message ----- From: "Thomas DeWeese" <[EMAIL PROTECTED]>
To: "Batik Users" <[EMAIL PROTECTED]>
Sent: Wednesday, October 01, 2003 2:38 AM
Subject: Re: JSVGComponent dynamic DOM update, invokeAndWait threading
issue
Hi Denis.
It looks to me like you need to shut down your SVGStage.AnimationTimer before you 'unload' the current document (or load a new document). Since this class appears to be 'outside' of Batik there is no way for us to shut it down for you.
If it is really on a Java Timer I believe you can cancel them.
Denis Bohm wrote:
I'm having a problem reloading a document. The first time I try to
reload I
just get a blank page, on the second try to reload it seems to work.
But
sometimes on the second reload I get:
java.lang.IllegalStateException: RunnableQueue not started or has
exited
org.apache.batik.util.RunnableQueue.invokeAndWait(RunnableQueue.java:257)at
at com.fireflydesign.svg.SVGStage$AnimationTimer.run(SVGStage.java:639)
and things don't function anymore.
I assume that I need to shut somethings down before changing the
document?
Is that what you are referring to when you say "don't load new SVG
documents
until pending DOM updates"?
Thanks, Denis
----- Original Message ----- From: "George Armhold" <[EMAIL PROTECTED]>
To: "Batik Users" <[EMAIL PROTECTED]>
Sent: Monday, September 29, 2003 12:29 PM
Subject: Re: JSVGComponent dynamic DOM update, invokeAndWait threading
issue
Sorry for the late reply to this thread; I was travelling when your reply came in.
Thomas DeWeese wrote:
So now my question is: how can I know when it's safe to call UpdateManager um = getUpdateManager(); RunnableQueue rq = um.getUpdateRunnableQueue();
and add things to the RunnableQueue?
It is safe after the first GVT rendering completes. This is _before_ the managerStarted call back, so this shouldn't be the problem. You should have enough instrumentation in your code now to figure out what the sequence of events is that leads to the Null UpdateManager is.
Indeed, thanks to your help. It seems there were two key issues in my code:
- make sure sure UpdateManager is available (wait until gvtRenderingCompleted event) before starting DOM updates.
- don't load new SVG documents until pending DOM updates (UpdateManager's RunnableQueue) to the currently loaded doc have completed.
Although I need to complete more testing, I have not seen any more crashes since applying these two fixes. Thanks!
-- George Armhold Rutgers University eLearning Grant, DCIS
--------------------------------------------------------------------- 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]
--------------------------------------------------------------------- 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]
--------------------------------------------------------------------- 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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
