xmlgraphics-batik-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Denis Bohm" <de...@fireflydesign.com>
Subject Re: JSVGComponent dynamic DOM update, invokeAndWait threading issue
Date Wed, 01 Oct 2003 18:49:59 GMT
That did it!  Thanks!

----- Original Message ----- 
From: "Thomas DeWeese" <Thomas.DeWeese@Kodak.com>
To: "Batik Users" <batik-users@xml.apache.org>
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" <Thomas.DeWeese@Kodak.com>
> > To: "Batik Users" <batik-users@xml.apache.org>
> > 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" <Thomas.DeWeese@Kodak.com>
> >>>To: "Batik Users" <batik-users@xml.apache.org>
> >>>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" <armhold@cs.rutgers.edu>
> >>>>>To: "Batik Users" <batik-users@xml.apache.org>
> >>>>>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: batik-users-unsubscribe@xml.apache.org
> >>>>>>For additional commands, e-mail: batik-users-help@xml.apache.org
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>---------------------------------------------------------------------
> >>>>>To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
> >>>>>For additional commands, e-mail: batik-users-help@xml.apache.org
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>---------------------------------------------------------------------
> >>>>To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
> >>>>For additional commands, e-mail: batik-users-help@xml.apache.org
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>>---------------------------------------------------------------------
> >>>To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
> >>>For additional commands, e-mail: batik-users-help@xml.apache.org
> >>>
> >>>
> >>
> >>
> >>
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
> >>For additional commands, e-mail: batik-users-help@xml.apache.org
> >>
> >>
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
> > For additional commands, e-mail: batik-users-help@xml.apache.org
> >
> >
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: batik-users-help@xml.apache.org
>
>


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


Mime
View raw message