Hi Lukasz,
Lukasz Matuszczak wrote:
I can see different approaches to implement SVG and Swing mix.
1. Using JLayeredPane with custom layout manager.
2. Using JSVGCanvas as container (add method) - it is similar to first solution, but it's potentially easier to use JSVGScrollPane.
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.
Thierry Kormann in http://koala.ilog.fr/batik/mlists/batik-users/archives/msg01001.html suggests that it is possible, but i got stuck in event dispatching and repainting.
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.
Has anyone succeeded in making graphics node in GVT Tree based on Swing Component, making it interactive when showed in JSVGCanvas?
I would also be grateful for any thoughts about advantages and disadvantages of above approaches (espacially in the context of memory and processor usage).
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.
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.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
