Hi Steiner,
"Steiner, Dominik" <[EMAIL PROTECTED]> wrote on 05/09/2006
02:12:13 AM:
> Actually I'm already using the static tag. In my map <g> tag I'm doing
the following
> <g batik:static="true" id="map">
> But I'm not sure how much it actually helps. I checked out the Batik
source a
> while ago, right after there was a thread from Andreas mentioning the
patch.
> Or should I update again?
There were at least two updates to the patch so if you don't have the
latest it's probably worth updating...
> I could still try your idea of two canvases. I'm already putting all my
gps
> points into another <g> tag, so I would just build another svg document
with
> the same viewbox and sizes as the map one and put the gps points in
there...
I know that with this solution the underlying map will always be bit
blitted
as efficiently as possible. The static patch still has issues where the
tile
grids can shift can things can get messy.
> My update loop changes the <g> transform and the tooltip text which is
showing
> the current position in longitude and latitude... I'm wondering, if
updating
> the tooltip is really that expensive,
I doubt the tooltip update is the problem (although it should be easy
to
test, simply turn it off in your code and see how update times change).
> because I can't imagine that updating the transform attribute of a <g>
should
> be that expensive...
Changing the transform is quick but changing the transform requires the
old location and the new location on the canvas be rerendered. Are you
careful
not to touch the 'svg:text' in the group?
Here's a question do you check if the location of the group has changed
from
update to update? Do they all generally change or normally just a small
subset?
I don't think we try and detect when the updated transform is equal to the
old
transform.
> I'm updating all the points in one Runnable... so there's no chance for
> improvement there either...
>
> Thanks again for your help Thomas... :-)
Good luck!
> -----Ursprüngliche Nachricht-----
> Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Gesendet: Montag, 8. Mai 2006 23:54
> An: [email protected]
> Cc: [email protected]
> Betreff: Re: performance issue
>
> Hi Steiner,
>
> "Steiner, Dominik" <[EMAIL PROTECTED]> wrote on 05/08/2006
> 10:54:05 AM:
>
> > I had a similar post a while ago, and Thomas was able to help with my
> > performance issues. Requirements though have gone up and I?m testing
my
> svg
> > app with more gps points, i.e. I have a map (600 kb) and there can be
> around
> > 400 gps points on it displayed.
>
> You might be able to make use of the 'static' patch in Bugzilla.
> If the underlying map isn't moving much it can help a lot.
>
> > Basically what I do is I collect the gps updates which are coming from
> the
> > server and update the canvas every 2 seconds. During the canvas
updates
> I?m
> > getting peaks of 60 ? 70 % CPU power because of the rendering
involved.
> I?m
> > wondering if I can do something to improve that, or are the
requirements
> just
> > to high for batik to handle it?
>
> 400 pts is a bit high especially depending on how well spread out
> they are (if mostly uniformly spread out it could be more or less
> rerendering the entire document the each time).
>
> You could try splitting the document into to pieces and use two
> canvas's on top of each other (similar effect to how the static patch
> works, not quite as general but the current static patch has some
> cases where it's performance isn't much better than without it).
>
> > My gps points are plain circles with a text and a tooltip. All the
> elements
> > are inside a <g>. To update the points I transform the <g>. That hint
> with the
> > <g>-tag already helped me a lot. Is there anything more I can do?
>
> So your update loop simply changes the transform attribute on the
> 'g' elements?
>
> > Is there a way to do batch updates in batik, i.e. change the gps
points
> first and
> > afterwards let batik render the changes or is batik doing it like that
> already?
>
> If you update all of the points in one UpdateManager Runnable then
they
> are
> batched. If you are putting a runnable on for each point then they are
> not
> batched and moving to one runnable would be a _huge_ win.
>
> Hope that helps.
>
>
> ---------------------------------------------------------------------
> 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]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
