That did it! Thanks! ----- Original Message ----- From: "Thomas DeWeese" <[EMAIL PROTECTED]> To: "Batik Users" <[EMAIL PROTECTED]> Sent: Wednesday, October 01, 2003 11:34 AM Subject: Re: JSVGComponent dynamic DOM update, invokeAndWait threading issue
> Denis Bohm wrote: > > > 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 > > > >>>>> at > >>>>> > >>> > >>> > > org.apache.batik.util.RunnableQueue.invokeAndWait(RunnableQueue.java:257) > > > >>>>> 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
