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, 08 Feb 2005 10:56:06 GMT
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: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org

View raw message