To: "Batik Users" <batik-users@xml.apache.org>
Sent: Tuesday, January 18, 2005 1:54 PM
Subject: Re: Mix SVG with Swing - Swing GraphicsNode?
Thank you very much for Your answers, Thomas. I am new to the batik project and i'm really impressed with such a good response from the authors. Great job! Unfortunately I wasn't able to read your suggestions and comment on them earlier.
[..]
I can see different approaches to implement SVG and Swing mix.
[...]3. Using batik extension mechanism. It would be the best solution because all positioning, zooming, scrolling, painting, printing and so on, would be supported directly by batik. Also i could partially cover swing components by SVG shapes.
Well, it nearly works but the problem is that the JButton doesn't belong to Swing hierarchy so it won't repaint itself (for example to show that it's pressed down).
Unfortunately I don't know the internals of Swing well enough to
really help here, but I'll try and give some suggestions. I suspect
that when a component wants to 'update' it's self it calls one of the
repaint methods. I suspect that these repaint requests get forwarded
to the parent of the component. These then bubble up to the window
which triggers the actual update. If this is correct then you should
be able to provide a 'parent' for the button that will be notified
when the child wants to be repainted. The parent can then invalidate
the components region in the GVT tree (all this must happen in the
UpdateManager thread of course). Then the JSVGCanvas will request that the region in question be repainted.
I have two questions here: 1. How can I invalidate some regions in the GVT Tree? I know this must be a silly question, but I got lost a little bit in the Batik API :) 2. Do you think it is possible to provide a 'parent' in such way, that my swing extensions to batik will work not only in my application but also for example in squiggle browser? I'm afraid that solutions which assume an access to UpdateManager thread are not perfectly clean and universal. As far as I understand it, while I write batik extensions I have access only to BridgeContext (i get it as parameter of createGraphicsNode method), and to UserAgent through the BridgeContext.getUserAgent() method. Therefore I can't see the way to invalidate the components region in the GVT tree from that level.
[...]
One comment on this, is that the reason putting little animations out of the main document and into a transparent JSVGCanvas helps is because the 'background' can then be repainted from the offscreen image rather than having to walk the entire GVT tree looking for nodes or subtree's that intersect the animated region. So if you then move these canvas's back into the GVT tree you will have your old performance problem back because you will once again have to walk the whole GVT tree drawing everything under the animated region.
Well, thank you for this clarification. It puts in question the "batik extension" solution. If I understand it correctly, the only way to get a performance boost is to make JSVGCanvas (and thus GVT tree) "unaware" of my transparent JSVGCanvas components, so I am forced to use JLayeredPane (solution 1.) or JSVGCanvas as swing container (solution 2.)
Depending on the structure of the document what you really want/need is the 'static' CSS hint from SVG 1.2. If this were properly implemented in Batik it would allow subtree's to repaint themselves from offscreen images rather than re-rendering the subtree from scratch each time. I've done one or two sample implementations and was not satisfied with the results but I'm still looking into it.
That would solve a lot of problems, so I wish you good luck :).
Best regards
Lukasz Matuszczak
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
