You are viewing a plain text version of this content. The canonical link for it is here.
Posted to batik-users@xmlgraphics.apache.org by Philippe Converset <pc...@Qarbon.com> on 2003/09/18 12:29:02 UTC
Modifying GVT directly
Hi,
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.
Thanks,
Philippe
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: Modifying GVT directly
Posted by Thomas DeWeese <Th...@Kodak.com>.
Philippe Converset wrote:
> I'm doing my tests directly in Squiggle classes, I've added a
> setDocumentState() call just before setSVGDocument() in
> org.apache.batik.apps.svgbrowser.JSVGViewerFrame.documentLoadingCompleted()
This won't work (it's too late). That call to setSVGDocument is
notifying the frame components about the document, it isn't setting
the SVGDocument on the JSVGCanvas. You can call setDocumentState on
the svgCanvas right after it is created in the JSVGViewerFrame constructor
(say around line 611).
>
> Philippe
>
> Stefán Freyr Stefánsson wrote:
>
>>-----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 <ma...@xml.apache.org>
>>>>For additional commands, e-mail: batik-users-help@xml.apache.org <ma...@xml.apache.org>
>>>>
>>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org <ma...@xml.apache.org>
>>>For additional commands, e-mail: batik-users-help@xml.apache.org <ma...@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 <ma...@xml.apache.org>
>>For additional commands, e-mail: batik-users-help@xml.apache.org <ma...@xml.apache.org>
>>
>>
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: Modifying GVT directly
Posted by Philippe Converset <pc...@Qarbon.com>.
I'm doing my tests directly in Squiggle classes, I've added a
setDocumentState() call just before setSVGDocument() in
org.apache.batik.apps.svgbrowser.JSVGViewerFrame.documentLoadingCompleted()
Philippe
Stefán Freyr Stefánsson wrote:
>-----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
>
>
>
>
Re: Modifying GVT directly
Posted by Stefán Freyr Stefánsson <st...@althingi.is>.
-----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
Re: Modifying GVT directly
Posted by Philippe Converset <pc...@Qarbon.com>.
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
Re: Modifying GVT directly
Posted by Thomas DeWeese <Th...@Kodak.com>.
Philippe Converset wrote:
>
> Thomas DeWeese wrote:
>
>>
>> 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.
>>
> Do you think this refactoring would allow the JGVTComponent to render a
> GVT tree created by hand (not attached to any SVG document)?
The JGVTComponent can already do this (render a GVT tree created by hand).
It currently doesn't support dynamic updates of that tree.
> If so, then I'd like to give it a try to compare it with my current
> graphics node system (Jazz).
Ok, what do you need to know?
I would move the RepaintManager, and UpdateManager to the GVT
package, and break any dependencies on the bridge package. The
UpdateManager will likely need to be split (make a GVTUpdateManager),
some fancy footwork could I think avoid this, as most of the UpdateManager
dependencies on the bridge package appear to be fairly shallow but
because a fair number of people use the UpdateManager I would want to
at least keep a proxy in bridge anyways. So as long as we need a class
there might as well just keep the bridge dependent parts in it.
I think if you can move these two classes to the GVT package you
are 1/3 of the way there. You should run regard at this point and make sure
everything still works.
Next you need to start moving stuff from JSVGComponent to JGVTComponent.
The simple rule of thumb is if the method references UpdateManager it needs
to be moved to JGVTComponent (this is a lot of methods). The biggest
exception to this rule is methods that call things like dispatchSVGScrollEvent.
You will also need to move the concept of at least 'dynamic' vs 'static'
GVT Tree's to the JGVTComponent - I would probably take the path of least resistance
and also move the concept of 'interactive' to JGVTComponent.
The trickiest piece of this will be dealing with the 'nextUpdateManager'
stuff which to be quite honest I can't quite figure out the utility of :)
The basic idea is to associate an updateManager with the canvas while loading
a new document - presumably so if something goes wrong we haven't killed the
previous updatemanager but I don't see this working the way things are right
now.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: Modifying GVT directly
Posted by Philippe Converset <pc...@Qarbon.com>.
Thomas DeWeese wrote:
>
> 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.
>
Do you think this refactoring would allow the JGVTComponent to render a
GVT tree created by hand (not attached to any SVG document)? If so, then
I'd like to give it a try to compare it with my current graphics node
system (Jazz).
Philippe
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: Modifying GVT directly
Posted by Thomas DeWeese <Th...@Kodak.com>.
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