I've tried what you were saying on two different files: "mines.svg" and "anne.svg". It works on the first one without problem, the display always renders the GVT even if you zoom or resize (although it diverges from the DOM). As for the second file, no update manager is available through JSVGCanvas (it's a static document unlike the first one) even if the document state is manually set to ALWAYS_DYNAMIC. Any idea on how to retrieve a non null update manager?
Thanks for your help,
Philippe
Thomas DeWeese wrote:
Philippe Converset wrote:
In a previous thread (04/02/2002), it's been said that JSVGComponent could not handle cases where the GVT tree is directly modified (there is no repaint). Is it still the case? If so, then would it be a hard work to add such a feature? The idea behind is to be able to the GVT packages without DOM.
If you want to modify the GVT tree directly you still need to go through the UpdateManager runnable queue. It is my belief that if you do this the repaint will happen. The real issue is that the JSVG* components are built around SVG and they are where dynamic changes are currently handled. The JGVTComponent is SVG/DOM independent but currently has no UpdateManager (I believe this is what Stephane was refering to). As a test make a runnable that changes the fill or shape of a shape node directly and add it to the UpdateManager's runnable queue on a JSVGCanvas - the screen should update (this is what happens indirectly when you modify the DOM).
If I am right (and I would be interested in knowing) the problem is that you can't use this really since, first the DOM is still attached to the GVT and second things might get really confused if the DOM and GVT diverge.
So I think the majority of the work in making a dynamic GVT component would be moving some pieces from the JSVGComponent down into the JGVTComponent (most notably the UpdateManager, and the associated repaint infrastructure). In other words this would be almost all refactoring of existing code - I would have to spend a lot more time looking at class dependencies to know exactly how complex the refactoring is. My gut feeling is that the refactoring would not be terribly complex and would likely improve the structure of the Batik components.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
