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 Wed, 08 Oct 2003 20:23:38 GMT
Thomas DeWeese wrote:

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

Yes.

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

I agree, it's because I am modifying the DOM outside of the
UpdateManager's thread.  Here's a stack trace.

java.lang.NullPointerException
	at org.apache.batik.bridge.CSSUtilities.convertDisplay(Unknown Source)
	at 
org.apache.batik.bridge.AbstractGraphicsNodeBridge.getDisplay(Unknown 
Source)
	at org.apache.batik.bridge.GVTBuilder.build(Unknown Source)
	at org.apache.batik.bridge.SVGGElementBridge.handleElementAdded(Unknown 
Source)
	at 
org.apache.batik.bridge.SVGGElementBridge.handleDOMNodeInsertedEvent(Unknown 
Source)
	at 
org.apache.batik.bridge.BridgeContext$DOMNodeInsertedEventListener.handleEvent(Unknown 
Source)
	at org.apache.batik.dom.events.EventSupport.fireEventListeners(Unknown 
Source)
	at org.apache.batik.dom.events.EventSupport.dispatchEvent(Unknown Source)
	at org.apache.batik.dom.AbstractNode.dispatchEvent(Unknown Source)
	at 
org.apache.batik.dom.AbstractParentNode.fireDOMNodeInsertedEvent(Unknown 
Source)
	at org.apache.batik.dom.AbstractParentNode.appendChild(Unknown Source)
	at edu.rutgers.elearning.util.SVGUtils.newScribbleGroup(SVGUtils.java:87)
	at 
edu.rutgers.elearning.scribble.ScribbleComponent.addScribbleGroup(ScribbleComponent.java:968)
	at 
edu.rutgers.elearning.presenter.Presenter.saveCurrentSlide(Presenter.java:903)
	at 
edu.rutgers.elearning.presenter.Presenter.displaySlide(Presenter.java:1020)
	at edu.rutgers.elearning.presenter.Presenter.access$400(Presenter.java:79)
	at 
edu.rutgers.elearning.presenter.Presenter$14.actionPerformed(Presenter.java:617)
	at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1786)
	at 
javax.swing.AbstractButton$ForwardActionEvents.actionPerformed(AbstractButton.java:1839)
	at 
javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:420)
	at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:258)
	at 
com.sun.java.swing.plaf.gtk.SynthButtonListener.mouseReleased(SynthButtonListener.java:250)
	at java.awt.Component.processMouseEvent(Component.java:5100)
	at java.awt.Component.processEvent(Component.java:4897)
	at java.awt.Container.processEvent(Container.java:1569)
	at java.awt.Component.dispatchEventImpl(Component.java:3615)
	at java.awt.Container.dispatchEventImpl(Container.java:1627)
	at java.awt.Component.dispatchEvent(Component.java:3477)
	at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:3483)
	at java.awt.LightweightDispatcher.processMouseEvent(Container.java:3198)
	at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3128)
	at java.awt.Container.dispatchEventImpl(Container.java:1613)
	at java.awt.Window.dispatchEventImpl(Window.java:1606)
	at java.awt.Component.dispatchEvent(Component.java:3477)
	at java.awt.EventQueue.dispatchEvent(EventQueue.java:456)
	at 
java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:201)
	at 
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:151)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:145)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:137)
	at java.awt.EventDispatchThread.run(EventDispatchThread.java:100)


 > There is a set of UpdateManagerEvents that you can listen to, in
 > order to know when it has shut down.

Which thread are the UpdateManagerEvents fired in?  The javadoc
documentation implies that they run in Swing.  Which means I'd
deadlock if I blocked waiting for them, since my event is also running
in the Swing thread.  Unless I spawned a new thread for each Swing
event, which is kind of a mess.

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

Well I place an SVG doc into the canvas, let the user modify it, and
then unload it (actually, load a new doc.)  Then I modify the
(unloaded) doc to adjust some of the settings before saving the XML to
a file.  The modifications after unload are just the logic of my app;
nothing that needs to be displayed.  The trouble seems to stem from
the fact that I'm not properly waiting for the doc to be "unloaded"
from the canvas.

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

Yeah, this is what I am afraid of.  It would really complicate things
to propagate the "queueness" of the canvas to the rest of our app.
I'm trying to isolate all of the batik event handling to my canvas
extension, and keep it as much a black box as possible.  We need
synchronous behavior for the rest of the app (load the doc, modify it,
unload it, install next doc.)

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

Ah, so maybe the UpdateManager's events are not fired from the Swing
thread after all?




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