xmlgraphics-batik-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bishop, Michael W. CONTR J9C880" <Michael.Bis...@je.jfcom.mil>
Subject RE: "Refreshing" the JSVGCanvas...
Date Thu, 09 Feb 2006 18:31:04 GMT
No, I don't call setRendering transform there, I call it in the
ActionListener for the Refresh button.  I needed a separate listener so
I would be able to tell the application when the RunnableQueue and the
UpdateManager were available.  It was suggested to me on this list to
have a GVT listener for that purpose.

Your approach sounds like it could work; I don't know enough about the
inner workings of Batik.  I already subclass JSVGCanvas to handle
resizing the component, so it wouldn't be too much additional work.

Would be nice to get some feedback on this approach though and see if
it's the right way to approach this stuff.  If I can trap the rendering
in the JSVGCanvas, maybe my GVT listener is superfluous.

Michael Bishop

-----Original Message-----
From: Scott Ruffner [mailto:sruffner@phy.ucsf.edu] 
Sent: Thursday, February 09, 2006 11:51 AM
To: batik-users@xmlgraphics.apache.org
Subject: Re: "Refreshing" the JSVGCanvas...

hi, michael --

i'm not sure about the exception you are getting, but 
it may have to do with the multithreaded machinery 
of Batik.  do you call setRenderingTransform() in 
your GVTTreeRendererAdapter.gvtRenderingCompleted() 
method?  JSVGComponent (superclass of JSVGCanvas)
also has a GVTTreeRendererListener, and its 
gvtRenderingCompleted() method does some important 
cleanup stuff.  If your listener gets called first, maybe 
that's the problem....

underneath the hood of JSVGCanvas, the rendering 
transform ultimately gets reset by a call to 
JSVGComponent.setGraphicsNode(), which is invoked 
after the GVT tree build phase is done, and immediately 
before scheduling the render phase.  This happens in 
JSVGComponent.SVGListener.gvtBuildCompleted():
   JSVGComponent.this.setGraphicsNode(...)
   scheduleGVTRendering() ==> calls renderGVTTree().

if it is not too difficult, and if the batik experts out 
there think it is a reasonable solution, you might 
try subclassing JSVGCanvas like so:

class MyCanvas extends JSVGCanvas 
{
   AffineTransform preservedRenderXfm = null;
   boolean usePreservedRenderXfm = false;
   ....
   public void refreshCanvas( SVGDocument theCurrentSVGDoc )
   {
       preservedRenderXfm = new AffineTransform( getRenderingTransform()
);
       usePreservedRenderXfm = true;
       setSVGDocument( theCurrentSVGDoc );
   }
   ....
   protected void renderGVTTree()
   {
       if( usePreservedRenderXfm )
      {
          usePreservedRenderXfm = false;
          setRenderingTransform( preservedRenderXfm, false );
       }
       super.renderGVTTree();
   }
}

This is simplified because there are multithreading issues to 
worry about (what if the user clicks "Refresh" button in rapid 
succession?).  I do something like this in my Batik-based app, 
and it works for me.  Doing it this way avoids having to go 
through two render phases, by the way.

good luck!

scott
-- 
Scott A. Ruffner, Scientific Programmer/Analyst
Lisberger Lab
W.M. Keck Foundation Center for Integrative Neuroscience
University of California -- San Francisco
513 Parnassus Avenue, Box 0444, S871
San Francisco, CA  94143-0444
415-502-7897

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

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


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

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


Mime
View raw message