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 peterhi <hy...@hotmail.com> on 2007/03/27 16:57:34 UTC
Best practices when updating dom
What are the do's and don'ts to ensure that updating the graphics by
manipulating the DOM can be as fast as possible. All advices are welcome.
--
View this message in context: http://www.nabble.com/Best-practices-when-updating-dom-tf3473646.html#a9694156
Sent from the Batik - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: Best practices when updating dom
Posted by peterhi <hy...@hotmail.com>.
I guess what "disconnect" means removing the node from the active document,
then you make the changes, afterwards, you put it back to the document.
Basically it is a removeChild() -> update your stuff -> appendChild() thing.
Another doubt is this: Let's say if i want a rect act as a background to
capture mouse motions in order to manipulate shapes like dragging or
resizing etc. Would it be faster to write the handling code using java and
batik, or, would it be faster to write all the handling logics inside the
document, embedded using javascript, and load it from batik?
--
View this message in context: http://www.nabble.com/Best-practices-when-updating-dom-tf3473646.html#a9778864
Sent from the Batik - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: Best practices when updating dom
Posted by Steffen Jacobs <sj...@informatik.uni-kiel.de>.
thomas.deweese@kodak.com schrieb:
> Hi Peter,
>
> peterhi <hy...@hotmail.com> wrote on 03/27/2007 10:57:34 AM:
>
>
>> What are the do's and don'ts to ensure that updating the graphics by
>> manipulating the DOM can be as fast as possible. All advices are
>>
> welcome.
>
> Aside from the requirement that all changes be made in the
> UpdateManager's
> thread, there are some things that can be done that may help in some
> cases.
>
> 1) If you will be making lots of changes to a subtree/element it can be
> faster
> to disconnect the tree from the document before making the changes. This
> avoids the overhead of keeping the GVT tree in synch with every change
> (think about a rect where you might set up to 6 attributes to change the
> rect; x, y, width, height, rx, ry). For simple changes it is better
> to do it in place (if you just change fill color for example).
>
Hi,
this sounds quite interesting for me, too. I would like to know how to
'disconnect' a GVT tree from the document, as I have to do a lot of
changes at different positions in one update step. At the moment, the
performance per step seems to be rather bad (appr. 150ms).
Thanks and best regards,
Steffen
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: Font Metrics
Posted by th...@kodak.com.
Hi Dylan,
"Dylan Browne" <dy...@mango-solutions.com> wrote on 04/03/2007 10:19:30
AM:
> If I am rendering a specified font in SVG, say Verdana, is there anyway
to
> ascertain information about the font rendering. What I need to get hold
of
> is the ascent and descent so I am able to layout text correctly.
>
> I am guessing to be able to do this I need to get hold of the Font
Metrics
> object, and to do that would require access to the Graphics object?
The Graphics object won't help that much actually. If you are using
a "Platform Font" then you can just use the Standard Java API's to get
the font metrics. If you are using an SVG Font, this is quite a bit
more complex as the construction of an SVG Font Instance requires a
text element hooked into the CSS cascade. In fact the easiest way
to get this would be to build an SVG text element and then get the
Font associated with the GVT Graphics node.
The method:
BridgeContext.getGraphicsNode(Element)
Can be used to get the batik.gvt.TextNode that is associated
with an SVG Text Element. From that you can get the
AttributedCharacterIterator, from which you can get the Font by
looking get the value for the TextAttribute:
batik.gvt.text.GVTAttributedCharacterIterator.GVT_FONT.
> I am creating my SVG using Batik DOM, so am also guessing this is not
> possible? In which case I should define my own font, or use a true
> type font and convert it to SVG font using ttf2SVG?
It is possible although as you can see from the sketch above
it's not real easy (unless you are only concerned with Platform
fonts).
> Hope my questions make sense, and thanks in advance for any help.
Good luck!
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Font Metrics
Posted by Dylan Browne <dy...@mango-solutions.com>.
Hi,
If I am rendering a specified font in SVG, say Verdana, is there anyway to
ascertain information about the font rendering. What I need to get hold of
is the ascent and descent so I am able to layout text correctly.
I am guessing to be able to do this I need to get hold of the Font Metrics
object, and to do that would require access to the Graphics object?
I am creating my SVG using Batik DOM, so am also guessing this is not
possible? In which case I should define my own font, or use a true type font
and convert it to SVG font using ttf2SVG?
Hope my questions make sense, and thanks in advance for any help.
Kind regards,
Dylan.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: Best practices when updating dom
Posted by th...@kodak.com.
Hi Peter,
peterhi <hy...@hotmail.com> wrote on 03/27/2007 10:57:34 AM:
> What are the do's and don'ts to ensure that updating the graphics by
> manipulating the DOM can be as fast as possible. All advices are
welcome.
Aside from the requirement that all changes be made in the
UpdateManager's
thread, there are some things that can be done that may help in some
cases.
1) If you will be making lots of changes to a subtree/element it can be
faster
to disconnect the tree from the document before making the changes. This
avoids the overhead of keeping the GVT tree in synch with every change
(think about a rect where you might set up to 6 attributes to change the
rect; x, y, width, height, rx, ry). For simple changes it is better
to do it in place (if you just change fill color for example).
2) If anything in a used subtree is changed all of the use instances
will
be rebuilt from scratch. So it's much better to disconnect change
attach if you are modifying used content.
3) Text is really painfully slow. The text layout is what takes the
most time so try to ensure what ever you do you only cause the
text to layout once.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org