xmlgraphics-batik-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefán Freyr Stefánsson <stef...@althingi.is>
Subject Re: Modifying GVT directly
Date Thu, 18 Sep 2003 13:44:56 GMT
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi.

Where are you manually setting the document state?  I found out that I _had_ 
to do it before calling setDocument()... otherwise I always got a null update 
manager.

Regards, Stefan.

On Thursday 18 September 2003 13:12, Philippe Converset wrote:
> Thomas,
>
> 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: batik-users-unsubscribe@xml.apache.org
> > For additional commands, e-mail: batik-users-help@xml.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: batik-users-help@xml.apache.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iQEVAwUBP2m2270ge6mq4AL2AQJEZggApnJmvWOEqGR9ezOjhkC1dZzY8j/F6yev
LjzQNd+SXIJroxCGW175Yxnniww9SFu2kRO7YH/ZyscWhafsVK0ULwO++A7q2Gif
PT+cbTP/dd+8hl5pl85KK3yzHziS8rvnYXx27gusBgKwOuReyFrPfMSUWvQcOdxS
tDksrgGEfSM6lS3XrngBvnBKpY0Q7nDZY426vN6jM+VQb/BWiW+ZzpdkpKpdaddU
hL9kOou+Z+01R7nom4KrRvXnpeEMeSvIQygdf/v74VcbAiQTiLsNcsZGr4OGolp/
dhqByVwcbvuLR4bsd1utWqTQhgiHtef0gCYwcz6/L+EFJFqcOZpOsA==
=CIti
-----END PGP SIGNATURE-----


---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org


Mime
View raw message