xmlgraphics-batik-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bishop, Michael W. CONTR J9C880" <michael.bishop....@jfcom.mil>
Subject RE: Rendering transform on refresh?
Date Wed, 29 Oct 2008 13:21:30 GMT
Hi Dan,
I think you indirectly answered my question and also gave me an idea to keep in mind.  I never
thought about preserving the "last" render/transform.  What I want to do with setDocument()
is have it communicate the "default" transform.
For some reason, if I call setDocument(), then fire my event, I'm still getting the "old"
transform.  I want what I think you described as the identity transform.
I need to communicate three points in my event; the upper-left, upper-right, and lower-left
of the JSVGCanvas window *in document coordinates* after the "refresh" has occurred.
You're describing preserving changes BEFORE setDocument(), I'm trying to capture the state
AFTER setDocument() and can't figure out what I need to wait for to get points after the document
has refreshed.
It sounds like I *could* eliminate the call to setDocument() entirely and simply set the rendering
transform to the identity transform (thus refreshing the document), then fire my event?


From: Dan Slater [mailto:dslater@simulsoft.com]
Sent: Tue 10/28/2008 6:32 PM
To: batik-users@xmlgraphics.apache.org
Subject: RE: Rendering transform on refresh?

Please forgive the multiple posts...for some reason a follow-up posted
before this original (now w/minor edit), and I haven't yet received the
original :( .  I think with plain text I'll have better success...

Hi, Michael,

I think I might have the answer.  I use a crude undo function to reset
the document, but found the render to reset each time.  Here's what
worked for me:

In your extended JSVGCanvas, place an instance field to store the last
render transform, and create getter/setter.  In the constructor, set the
identity transform since this is the default when the canvas is first
booted. Then override svgLoadEventDispatchCompleted with a call to
setRenderingTransform, which in turn you've already overridden per
recent threads.

When this is all prepared, call
svgCanvas.setLastRender(svgcanvas.getrenderingtransform) (or use
whatever transform you wish) and the canvas render should automatically
reset after you call setSVGDocument.

I can't tell you how much time it took to test the rendering transform
in all the event listeners...it's instructive but it would have been
extremely helpful to have a concise reference for the complete
JSVGCanvas event sequence.  Hope this helps some others out there...if
anybody knows how to set a listener on the canvas for when the rendering
transform changes (I tried and gave up), or has a better way, I'd love
to hear about it.

    public class JSVGCanvasX extends JSVGCanvas {
        private AffineTransform lastRender = new AffineTransform();
        public JSVGCanvasX() {
SVGLoadEventDispatcherAdapter() {
                public void
svgLoadEventDispatchCompleted(SVGLoadEventDispatcherEvent e){
                    //set the rendering transform here, after
SVGDocument is loaded but before rendering occurs
                    //canvas transform resets to identity before this
event is fired

Dan Slater

-------- Original Message --------
Subject: Rendering transform on refresh?
From: "Bishop, Michael W. CONTR J9C880" <michael.bishop.ctr@jfcom.mil>
Date: Tue, October 28, 2008 3:41 pm
To: <batik-users@xmlgraphics.apache.org>

I have a refresh function in my application that simply calls
setDocument() on the JSVGCanvas with the document already there,
basically causing it to reset to its default state without

I'm also tracking changes to my rendering transform, but keying off
setRenderingTransform() doesn't seem to work; it seems to be called
before the "final" transform is achieved.

What can I wait for to determine when the rendering transform is "done"
and ready to be communicated? Maybe computeRenderingTransform? I've
tried waiting for the GVT tree to render and for the SVG "onLoad" event,
but both seem to be too early and not communicating any change.


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

View raw message