xmlgraphics-batik-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From George Armhold <armh...@cs.rutgers.edu>
Subject Re: JSVGComponent dynamic DOM update, invokeAndWait threading issue
Date Thu, 18 Sep 2003 18:58:30 GMT

Thanks again for yet another speedy response.

> This would indicate to me that the MouseReleased code is running
> after the load event (the getUpdateManager call is before the call
> to invokeAndWait so it's hard to blame a null return from getUM on
> invokeAndWait :).  

Yes, it sure looks that way.  But assuming that Swing fires event
sequentially, it should mirror what the user is doing- MousePressed,
MouseDragged, MouseReleased, click on "load new SVG" button.

> The JSVGCanvas tries to be very good about this cases so even if you
> did an invokeLater it should wait until your runnable ends before
> disposing of the document.

OK, good to know that.

> Just picking on words here you say "after MouseReleased event" is
> this happening _in_ the mouseRelease callback, or is it code
> triggered by the mouse release callback?

Oops.  I should have said that the code is called INSIDE the
MouseReleased callback.  So the call to "invokeAndWait" is running in
the Swing/AWT thread.

>> So I guess my question is the following: how can I dynamically and
>> synchronously update the DOM via Swing/AWT events?  I need to block
>> until the update completes.  
>     The above should do it (although I really suspect that you don't
> need to block in this case if you are just throwing away the document
> anyway).

Well the problem is that I'm not throwing the document away.  It's
true that if the user loads a new doc before the screen is done
updating from the new DOM elements, this presents no crisis.  However
I *do* care that the doc is properly updated, because I then retrieve
the doc from the JSVGComponent and save it to disk, with the newly
added <line> elements.  This is why I was trying to make the Swing
thread block until the DOM was updated- to prevent the user from being
able to click the "load new document" button until all elements were

> Yes invokeAndWait from the AWT thread is bad because some DOM calls
> require calling back to the AWT thread which will cause a deadlock.
> You can safely use it from a third thread.  But this is _not_ the
> issue you are having (well it might be the freeze issue).

OK this explains my GUI hangs then.  I don't recall seeing them when I
was doing invokeLater.

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

View raw message