You are viewing a plain text version of this content. The canonical link for it is here.
Posted to batik-dev@xmlgraphics.apache.org by Brian Modra <bm...@pcorp.com.au> on 2003/07/07 07:36:44 UTC
RunnableQueue bug/weakness
Hi, in org.apache.batik.util.RunnableQueue, where it calls the link's
run() method, its vulnerable - because any exceptions thrown in the
run() method will cause the queue to stop.
here's a simple fix:
from line 163 (or thereabout depending on what version you have)
instead of this:
rable.run();
l.unlock();
runnableInvoked(rable);
wrap the run() in a try { ... } catch... :
try {
rable.run();
}
catch (Throwable e) {
e.printStackTrace();
}
l.unlock();
runnableInvoked(rable);
.... 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org
Re: RunnableQueue bug/weakness
Posted by Brian Modra <bm...@pcorp.com.au>.
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: batik-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: batik-dev-help@xml.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org
Re: RunnableQueue bug/weakness
Posted by Thomas DeWeese <Th...@Kodak.com>.
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: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org
Re: RunnableQueue bug/weakness
Posted by Brian Modra <bm...@pcorp.com.au>.
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.
On Mon, 2003-07-07 at 21:53, Thomas DeWeese wrote:
> Brian Modra wrote:
>
> >Hi, in org.apache.batik.util.RunnableQueue, where it calls the link's
> >run() method, its vulnerable - because any exceptions thrown in the
> >run() method will cause the queue to stop.
> >here's a simple fix:
> >from line 163 (or thereabout depending on what version you have)
> >
> >instead of this:
> > rable.run();
> > l.unlock();
> > runnableInvoked(rable);
> >
> >wrap the run() in a try { ... } catch... :
> >
> I agree that because lots of people are now using the runnable queue
> we should
> do this. Thanks for pointing it out.
>
> >.... 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: batik-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: batik-dev-help@xml.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org
Re: RunnableQueue bug/weakness
Posted by Thomas DeWeese <Th...@Kodak.com>.
Brian Modra wrote:
>Hi, in org.apache.batik.util.RunnableQueue, where it calls the link's
>run() method, its vulnerable - because any exceptions thrown in the
>run() method will cause the queue to stop.
>here's a simple fix:
>from line 163 (or thereabout depending on what version you have)
>
>instead of this:
> rable.run();
> l.unlock();
> runnableInvoked(rable);
>
>wrap the run() in a try { ... } catch... :
>
I agree that because lots of people are now using the runnable queue
we should
do this. Thanks for pointing it out.
>.... 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: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org