You are viewing a plain text version of this content. The canonical link for it is here.
Posted to batik-dev@xmlgraphics.apache.org by Harm Cuppens <ha...@iosint.be> on 2003/05/22 11:26:28 UTC
Layered JSVGCanvasses
Hello all,
The goal is to reduce memory usage.
In my application I make use of converted autocad drawings (converted to
svg). Due to the complexity of the drawings a lot of memory is required
to create the dom tree and the corresponding gvt tree. The drawings
don't have to be manipulated, they are static, but it is my goal to add
svg elements on top of the drawing that don't have to be part of the
drawing svg document. Think of it as a piece of paper with a drawing on
it, and placing a transparent piece of paper on top of that on which you
actually draw.
Would it be possible to have two JSVGCanvases rendering on top of each
other (the lower one being static containing my autocad drawing, the
upper one being dynamic used to draw things) by using a JLayeredPane
perhaps. Zooming and panning should still work if I sent the zoom
request to both canvasses.
Am I even correct to believe that the dom tree is unnecessary for static
documents and can be garbage collected (after the dom is converted to
gvt of course)?
If the dom tree is required even for static JSVGComponents does anybody
have ideas on another approach I could take ?
Thanks
Harm
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org
Re: Layered JSVGCanvasses
Posted by Vincent Hardy <vi...@sun.com>.
Hi Thomas,
I like your proposal a lot and I think it aligns well with the SVG
language. I also think that the current notion of static is confusing
(at best) as it does include interactivity features.
Vincent.
Thomas E Deweese wrote:
>>>>>>"VH" == Vincent Hardy <vi...@sun.com> writes:
>>>>>>
>>>>>>
>
>VH> If you look at the org.apache.batik.bridge.GVTBuilder's build
>VH> method, you'll see that we hook listeners to the DOM tree to be
>VH> able to have the proper cursor behavior. So even for a 'static'
>VH> document, we use the DOM to implement that behavior. We also use
>VH> the DOM for 'static' documents to implement anchors (see the
>VH> SVGAElementBridge).
>
> On this point what would people think about making the document
>state quad stated:
>
> ALWAYS_DYNAMIC -> everything hooked up for dynamic documents
> ALWAYS_STATIC -> no listeners of any kind registered
> ALWAYS_INTERACTIVE -> Document can't change but cursor/anchor work
> AUTODETECT -> At least initially just select between
> INTERACTIVE and DYNAMIC eventually may
> choose STATIC if no anchor or cursor
> elements/properties are present.
>
> Eventually it might be possible to make ALWAYS_INTERACTIVE not
>depend on DOM (by providing the needed info to GVT). However for
>dynamic documents it must go through DOM so script can listen and
>intercept the events (so it requires two implementations of these
>features).
>
> The only issue I see here is that the current meaning of
>ALWAYS_STATIC will change to ALWAYS_INTERACTIVE. We could have
>ALWAYS_STATIC_AND_I_MEAN_IT, or ALWAYS_STATIC_NO_DOM.
>
> But I think most people will be a little surprised that
>ALWAYS_STATIC currently supports anchors/cursors and so won't mind.
>Those that want just these features just have to change to use
>ALWAYS_INTERACTIVE.
>
>VH> However, I think that if you provied a UserAgent to the
>VH> BridgeContext that has no event dispatcher, there will be no hooks
>VH> between the DOM tree and the GVT tree (even though there will be
>VH> listeners on the DOM tree) and you should have the DOM garbage
>VH> collected (see BrideEventSupport.addGVTListener). In this case,
>VH> anchors and cursors won't work though, but it may not be an issue
>VH> in your case.
>
>VH> I hope this helps, Vincent.
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org
RE: Layered JSVGCanvasses
Posted by Thierry Kormann <tk...@ilog.fr>.
> On this point what would people think about making the document
> state quad stated:
>
> ALWAYS_DYNAMIC -> everything hooked up for dynamic documents
> ALWAYS_STATIC -> no listeners of any kind registered
> ALWAYS_INTERACTIVE -> Document can't change but
> cursor/anchor work
> AUTODETECT -> At least initially just select between
> INTERACTIVE and DYNAMIC eventually may
> choose STATIC if no anchor or cursor
> elements/properties are present.
I think this is a good idea.
Thierry.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org
Re: Layered JSVGCanvasses
Posted by Thomas E Deweese <th...@kodak.com>.
>>>>> "VH" == Vincent Hardy <vi...@sun.com> writes:
VH> If you look at the org.apache.batik.bridge.GVTBuilder's build
VH> method, you'll see that we hook listeners to the DOM tree to be
VH> able to have the proper cursor behavior. So even for a 'static'
VH> document, we use the DOM to implement that behavior. We also use
VH> the DOM for 'static' documents to implement anchors (see the
VH> SVGAElementBridge).
On this point what would people think about making the document
state quad stated:
ALWAYS_DYNAMIC -> everything hooked up for dynamic documents
ALWAYS_STATIC -> no listeners of any kind registered
ALWAYS_INTERACTIVE -> Document can't change but cursor/anchor work
AUTODETECT -> At least initially just select between
INTERACTIVE and DYNAMIC eventually may
choose STATIC if no anchor or cursor
elements/properties are present.
Eventually it might be possible to make ALWAYS_INTERACTIVE not
depend on DOM (by providing the needed info to GVT). However for
dynamic documents it must go through DOM so script can listen and
intercept the events (so it requires two implementations of these
features).
The only issue I see here is that the current meaning of
ALWAYS_STATIC will change to ALWAYS_INTERACTIVE. We could have
ALWAYS_STATIC_AND_I_MEAN_IT, or ALWAYS_STATIC_NO_DOM.
But I think most people will be a little surprised that
ALWAYS_STATIC currently supports anchors/cursors and so won't mind.
Those that want just these features just have to change to use
ALWAYS_INTERACTIVE.
VH> However, I think that if you provied a UserAgent to the
VH> BridgeContext that has no event dispatcher, there will be no hooks
VH> between the DOM tree and the GVT tree (even though there will be
VH> listeners on the DOM tree) and you should have the DOM garbage
VH> collected (see BrideEventSupport.addGVTListener). In this case,
VH> anchors and cursors won't work though, but it may not be an issue
VH> in your case.
VH> I hope this helps, Vincent.
VH> Harm Cuppens wrote:
>> Hello all,
>>
>> The goal is to reduce memory usage. In my application I make use
>> of converted autocad drawings (converted to svg). Due to the
>> complexity of the drawings a lot of memory is required to create
>> the dom tree and the corresponding gvt tree. The drawings don't
>> have to be manipulated, they are static, but it is my goal to add
>> svg elements on top of the drawing that don't have to be part of
>> the drawing svg document. Think of it as a piece of paper with a
>> drawing on it, and placing a transparent piece of paper on top of
>> that on which you actually draw.
>>
>> Would it be possible to have two JSVGCanvases rendering on top of
>> each other (the lower one being static containing my autocad
>> drawing, the upper one being dynamic used to draw things) by using
>> a JLayeredPane perhaps. Zooming and panning should still work if I
>> sent the zoom request to both canvasses. Am I even correct to
>> believe that the dom tree is unnecessary for static documents and
>> can be garbage collected (after the dom is converted to gvt of
>> course)?
>>
>> If the dom tree is required even for static JSVGComponents does
>> anybody have ideas on another approach I could take ?
>>
>> Thanks Harm
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org For
>> additional commands, e-mail: batik-dev-help@xml.apache.org
>>
>>
>>
>>
VH> ---------------------------------------------------------------------
VH> To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org For
VH> additional commands, e-mail: batik-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org
Re: Layered JSVGCanvasses
Posted by Vincent Hardy <vi...@sun.com>.
Hi Harm,
If you look at the org.apache.batik.bridge.GVTBuilder's build method,
you'll see that we hook listeners to the DOM tree to be able to have the
proper cursor behavior. So even for a 'static' document, we use the DOM
to implement that behavior. We also use the DOM for 'static' documents
to implement anchors (see the SVGAElementBridge).
However, I think that if you provied a UserAgent to the BridgeContext
that has no event dispatcher, there will be no hooks between the DOM
tree and the GVT tree (even though there will be listeners on the DOM
tree) and you should have the DOM garbage collected (see
BrideEventSupport.addGVTListener). In this case, anchors and cursors
won't work though, but it may not be an issue in your case.
I hope this helps,
Vincent.
Harm Cuppens wrote:
>Hello all,
>
>The goal is to reduce memory usage.
>In my application I make use of converted autocad drawings (converted to
>svg). Due to the complexity of the drawings a lot of memory is required
>to create the dom tree and the corresponding gvt tree. The drawings
>don't have to be manipulated, they are static, but it is my goal to add
>svg elements on top of the drawing that don't have to be part of the
>drawing svg document. Think of it as a piece of paper with a drawing on
>it, and placing a transparent piece of paper on top of that on which you
>actually draw.
>
>Would it be possible to have two JSVGCanvases rendering on top of each
>other (the lower one being static containing my autocad drawing, the
>upper one being dynamic used to draw things) by using a JLayeredPane
>perhaps. Zooming and panning should still work if I sent the zoom
>request to both canvasses.
>Am I even correct to believe that the dom tree is unnecessary for static
>documents and can be garbage collected (after the dom is converted to
>gvt of course)?
>
>If the dom tree is required even for static JSVGComponents does anybody
>have ideas on another approach I could take ?
>
>Thanks
>Harm
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
>For additional commands, e-mail: batik-dev-help@xml.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org