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 22:18:42 GMT
Thomas DeWeese wrote:

 > Hmm you seem to be getting exceedingly unlucky here. :) The NPE is
 > caused by the BridgeContext dispose method disposing of the
 > CSSEngine (no display property anymore).  But the dispose of the
 > CSSEngine is done _after_ the BridgeContext DOM listeners are
 > removed from the Document.

Um, OK.  I didn't know that the CSSEngine was something I had to worry
about.  I'll add it to the list. ;-)

 > Well just my 2c but blocking the Swing thread is really bad behavior
 > for an application.

I agree in principle about not making Swing block.  In fact I just
finished code to farm off SVG -> BufferedImage rasterization in a
separate thread, to keep Swing "lively".  But I was assuming that the
time it takes to wait for the document unloading to happen was pretty

 > Heck the modification of the document to be written can be delayed
 > indefinitely.

Yes and no.  There is logic in the rest of our app that expects to get
the "old" document back from the canvas and "do stuff" with it.  Of
course we can install callbacks that are fired when the doc is really
unloaded, but our code is quickly turning into a tangled mess of such
callbacks.  But if I must, I must.  :-)

 >> final Document oldDoc = canvas.getSVGDocument();
 >> final UpdateManager um = canavs.getUpdateManager();
 >> um.addUpdateManagerListener(new UpdateManagerAdapter() {
 >>    public void managerStopped(UpdateManagerEvent e) {
 >>       um.removeUpdateManagerListener(this);
 >>       prepDocument(oldDoc);
 >>       writeDocument(oldDoc);
 >>    }
 >> };
 >> canvas.setSVGDocument(newDoc);

 > Hmm, there is a problem with this.  The BridgeContext isn't disposed
 > of until after all the managerStopped Listeners have been called.  I
 > don't think this is correct behavior, but until it's fixed you will
 > actually have to hang your listener off the document load or gvt
 > build listener to make sure the old document is no longer 'active'.

You mean I should install this listener after (say) gvtBuildCompleted?

Thanks as always for your wisdom!

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

View raw message