xmlgraphics-batik-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas DeWeese <Thomas.DeWe...@Kodak.com>
Subject Re: JSVGComponent dynamic DOM update, invokeAndWait threading issue
Date Wed, 08 Oct 2003 18:33:37 GMT
George Armhold wrote:

> I'm still struggling with threads in Batik.  A previously discussed
> recommendation was to "leave the canvas alone until
> gvtTreeRenderingComplete is fired".  However what does one do when the
> requests for updating the canvas/DOM are firing from the Swing thread?
> You can't block in the Swing thread, because the Batik events are
> apparently fired from there as well, so I'll never see
> gvtTreeRenderingComplete.  Here's the scenario:
> 1. Swing event triggers canvas.setSVGDocument(firstDoc).
> 2. manipulate firstDoc's DOM (in UpdateManger's thread) in response to
>    Swing mouse clicks, etc.
> 3. Swing event calls canvas.getSVGDocument() to get the modified
>    firstDoc back, and then canvas.setSVGDocument(secondDoc).

Hi George,

    So are we OK up to here?

> 4. manipulate firstDoc's DOM in Swing thread.
> I then get a NullPointerException, presumably because I am modifying
> the firstDoc DOM outside of the UpdateManager thread. 

   Well a stack trace would have helped to identify why you get
the NPE.  But my assumption is that you are modifying the firstDoc
before the UpdateManager that has been managing it is shut down.
There is a set of UpdateManagerEvents that you can listen to, in order
to know when it has shut down.

> The kind of
> situation that is triggering this behavior is when the user clicks the
> "load next SVG document" button too quickly in succession.

   It isn't clear to me why you are modifying the firstDoc's DOM
when it isn't being displayed or why going to the next SVG Document would
cause problems with 'previous' documents.

> Perhaps I am going about things the wrong way, because very often when
> using the canvas I end up trying all sorts of threading chicanery to
> simulate blocking for Batik's non-blocking methods.

   Well it sounds to me like you need to queue these user events until
the system can catch up with them.  I would suggest using something
like our RunnableQueue to do this.  This way the Swing thread can construct
a runnable to 'load the next document' and stick it in the runnable queue.
The first thing the runnable does is check that the canvas is 'stable' (Which
can block because we are out of the Swing thread) then it can install the
next document.  If the user has pressed 'load the next document' four times
in between you can either let the user wait for the 'intermediate' pages to
stop/start/stop/start or do a sort of 'event compression' where you
remove the earlier load events from the RunnableQueue (this is done for mouse
events in Batik).

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

View raw message