xmlgraphics-batik-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas DeWeese <Thomas.DeWe...@Kodak.com>
Subject Re: Mix SVG with Swing - Swing GraphicsNode?
Date Tue, 18 Jan 2005 12:54:07 GMT
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: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org

View raw message