Frequent document changes crash Batik

[th...@sympatico.ca]

I use javax.swing.Timer to drive an action to change the document from jSVGCanvas.getSVGDocument(), and do this:
 
                jSVGCanvas.setDocumentState(JSVGCanvas.ALWAYS_DYNAMIC);
                jSVGCanvas.setDocument(jSVGCanvas.getSVGDocument());
 
If the timer is too fast (delay<100 ms), it will eventually crash the Batik. If the timer is slow (delay>1000 ms), everything is fine.
 
I expect the JSVGCanvas to notify me with some events that the document changes are too frequent. Then I can dynamically slow down the timer. But it just crashes.
 
Any comments?

RE: Frequent document changes crash Batik

[th...@sympatico.ca]

Awesome! That is an excellent advice.

 

Now I can update the document 24 frames per second. Yeah, it is smooth like a movie.

 

Thanks.

 


To: batik-users@xmlgraphics.apache.org
CC: batik-users@xmlgraphics.apache.org
Subject: Re: Frequent document changes crash Batik
From: thomas.deweese@kodak.com
Date: Thu, 21 May 2009 05:45:49 -0400


Hi Networker,

<th...@sympatico.ca> wrote on 05/21/2009 01:52:32 AM:

> I use javax.swing.Timer to drive an action to change the document 
> from jSVGCanvas.getSVGDocument(), and do this:
>  
>                 jSVGCanvas.setDocumentState(JSVGCanvas.ALWAYS_DYNAMIC);
>                 jSVGCanvas.setDocument(jSVGCanvas.getSVGDocument());
>  
> If the timer is too fast (delay<100 ms), it will eventually crash 
> the Batik. If the timer is slow (delay>1000 ms), everything is fine.
>  
> I expect the JSVGCanvas to notify me with some events that the 
> document changes are too frequent. Then I can dynamically slow down 
> the timer. But it just crashes.
>  
> Any comments? 

   To start with if you are calling jSVGCanvas.getSVGDocument() 
then modifying the document and then setting the Document back 
on the canvas all within the Swing Timer then you are breaking 
the cardinal rule of dynamic document manipulation in Batik, 
namely all modifications to the document _must_ be done in 
the Canvas's UpdateManager's RunnableQueue, as an up side to 
doing this you can avoid the 'setDocument' call and things will 
run _much_ faster. 

   As far as getting feedback on changing the document too 
quickly, the canvas has callbacks for loading, rendering and 
update events which you can listen to.  Alternately when you 
start submitting your changes to the RunnableQueue as Runnables I 
would suggest notifying yourself when you have made the 
change at the end of your runnable, and then make sure you only 
submit one change to the runnable queue at a time. 

Re: Frequent document changes crash Batik

[th...@kodak.com]

Hi Networker,

<th...@sympatico.ca> wrote on 05/21/2009 01:52:32 AM:

> I use javax.swing.Timer to drive an action to change the document 
> from jSVGCanvas.getSVGDocument(), and do this:
> 
>                 jSVGCanvas.setDocumentState(JSVGCanvas.ALWAYS_DYNAMIC);
>                 jSVGCanvas.setDocument(jSVGCanvas.getSVGDocument());
> 
> If the timer is too fast (delay<100 ms), it will eventually crash 
> the Batik. If the timer is slow (delay>1000 ms), everything is fine.
> 
> I expect the JSVGCanvas to notify me with some events that the 
> document changes are too frequent. Then I can dynamically slow down 
> the timer. But it just crashes.
> 
> Any comments?

   To start with if you are calling jSVGCanvas.getSVGDocument()
then modifying the document and then setting the Document back
on the canvas all within the Swing Timer then you are breaking 
the cardinal rule of dynamic document manipulation in Batik,
namely all modifications to the document _must_ be done in
the Canvas's UpdateManager's RunnableQueue, as an up side to
doing this you can avoid the 'setDocument' call and things will
run _much_ faster.

   As far as getting feedback on changing the document too
quickly, the canvas has callbacks for loading, rendering and
update events which you can listen to.  Alternately when you 
start submitting your changes to the RunnableQueue as Runnables I
would suggest notifying yourself when you have made the
change at the end of your runnable, and then make sure you only
submit one change to the runnable queue at a time.