If the update manager has been suspended, then the next call to
JSVGComponent.renderGVTTree() will find that updateManager.isRunning()
is false, and therefore will call super.renderGVTTree() ... where
eventDispatcher.setRootNode(null) is called. So the resumeProcessing()
method in JSVGComponent needs to restore the event processor's root
node.
Maybe there is a less violent way to suspend event processing during a
rendering process, rather than setting the event processor's root node
to null?
I've had quite a few problems with batik renderining procesing stopping,
for strange reasons, and without any exceptions reported. So I've
started going through the sources looking for looping run methods which
don't have good exception handling. Here's what I've found:
SVGLoadEventDispatcher catches Exception. Throwable could be uncaught.
Same in SVGDocumentLoader, GVTTreeBuilder, GVTTreeRenderer
SoftReferencedCache, TileMap, RepaintRateManager have no try catch.
JGVTComponnet progressivePaintThread catches all Exceptions and reports
none. I would rather
} catch (InterruptedException ex) {}
} catch (Throwable ex) {
ex.printStackTrace();
}
On Wed, 2003-07-09 at 02:39, Thomas DeWeese wrote:
> Hi Brian,
>
> I'm still having a hard time understanding the problem. Searching
> the source base the only place
> we call setRootNode with 'null' is in JGVTComponent.renderGVTTree().
> This method is overridden
> by JSVGComponent, and the subclass only calls the baseclass version for
> documents that are not dynamic,
> for documents that are not dynamic (no update manger) suspendProcessing
> does nothing.
>
> For dynamic documents the eventDispatcher never has it's root set to
> null once the onload events have
> been dispatched (i.e. after the inital rendering - I have verified this)
> and the updateManager isn't installed
> until the first rendering completes (so a simple suspendProcssing() will
> still do nothing).
>
> Brian Modra wrote:
>
> >In my application, I call suspendProcessing when the component is
> >hidden, and resumeProcessing when it is displayed again. Since this
> >application is multi-threaded, and things are happening all the time,
> >causing updates to the graphics ... its quite likely that when
> >suspendProcessing is called it is in the middle of an update. So the
> >updae started, root was set to null, then suspendProcessing was called -
> >so the update was interrupted, and therefore gvtRenderingCompleted does
> >not get called, and the root node is not reset.
> >
> >
> >
> >>>.... also - this bugfix to JSVGComponent:
> >>>(To avoid loss of event handling after calling suspendProcessing().)
> >>>
> >>>public void resumeProcessing() {
> >>> if (updateManager != null) {
> >>> updateManager.resume();
> >>> setGraphicsNode(getGraphicsNode(), false);
> >>> }
> >>>}
> >>>
> >>>... because suspendProcessing is quite likely to get called inside of a
> >>>GVT rendering call, which first sets the event dispatcher's root node to
> >>>null.. and then once suspended, gvtRenderingCompleted (which would have
> >>>reset the node) never gets called.
> >>>
> >>>
> >>>
> >> I don't follow you here. The only place I can find that we call
> >>suspendProcessing is in response
> >>to the user pressing the 'pause' button. Is the intent to give the
> >>users a way to 'restart' event processing
> >>when something goes wrong? Pause/UnPause?
> >>
> >> It does appear that gvtRenderingCancelled/Failed should set the root
> >>node on the event dispatcher.
> >>
> >>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
