Hi Lukasz,
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).
> Thomas DeWeese wrote:
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.
Lukasz Matuszczak wrote:
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 :)
I could see how you might miss it. Changes in the GVT Tree are signaled by triggering a 'GraphicsNodeChangeEvent'. These events always come in pairs a 'started' and 'completed' event. In general the entire visible bounds of the node that fires the event are considered to be invalid.
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 would think so.
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.
Well the BridgeContext gives you access to almost everything, including the UpdateManager (which has the UpdateManager thread). The only word of caution I have is that 'caching' a reference to the BridgeContext is a bad idea for static documents (which I understand is not your area of interest). Ideally you would check if the BridgeContext is configured for dynamic and only cache a reference in that case (otherwise you just paint your currently working 'static' version).
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 [...]
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.)
Well, you could consider doing a bit of both (although it would be a bit more work). So extension elements could trigger the creation of Swing Components. The painting context for the swing components would come from the GVT tree (when the GraphicsNode was painted). This would be tricky!
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 :).
Yes, it really would solve a lot of problems and in general is likely a _very_ important optimization for a vector graphics language like SVG.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
