Hi Andreas,
Can you generate a few thread dumps during the
several minutes it's updating with the 'dynamic'
content?
You can do this by running squiggle in one terminal
window, and then in a second terminal window getting
the process id of the squiggle java process:
ps | grep java
The process number is the first number in the line
with /usr/bin/java.
Then start the 'update' and in the second
terminal window run:
kill -3 <java process number>
This should trigger a bunch of output in the
first terminal window (where you ran squiggle).
Doing this a few times during the update would
be helpful to see if it is just moving slowly through
the graphics tree or if it is hung up on a particular
call.
You might attach the output to the bugzilla
bug on this issue.
Andreas Neumann wrote:
Hi Thomas,
I replaced the DynamicRender.java file (in
trunk/sources/org/apache/batik/gvt/renderer/)
<cid:[email protected]>
, downloaded from
http://issues.apache.org/bugzilla/show_bug.cgi?id=36769, but it did not
help inmy case (Yosemite map). There is no noticable difference compared
to the old renderer.
Scott, if you try http://www.carto.net/williams/yosemite/index.svg in
your Mac/Tiger - is it as slow as it is on my machine?
Andreas
Thomas DeWeese wrote:
Hi Scott, Andreas,
I am at a bit of a loss what would cause such problems.
One possibility is that my use of a 'complex' clip path
to avoid multiple renders of the document is at fault. I've created
a new attachment to the bug that has a newer version of the Renderer
that uses something closer to the old code (multiple draws with
simple rect clips).
Scott Ruffner wrote:
Hi, Andreas and Thomas --
I wonder what I did different from scott? Is it because I have a G4 and
scott has a G5? Or because I applied the patch to the trunk (latest
developer version) instead of the older stable version?
I'm using a 800MHz G4 Powerbook, so our "testbeds" are
similar in that regard. I think Thomas answered your question
about the static document. My documents are always dynamic, so I
"cheated" by overriding JGVTComponent.createImageRenderer()
and instantiating the version of DynamicRenderer() that Thomas
provided in the patch. Complete refreshes of the canvas were back to
MacOSX 10.3/Batik 1.6 performance levels, but partial updates via
the canvas's UpdateManager were often terribly long (>15sec vs
~150millisecs
on WinXP).
I don't know much about how scripting and the getURL() stuff works,
but I'm guessing that if it is "remote" data, the UpdateManager is
responsible
for updating the canvas once the data has been retrieved. If so,
perhaps
the
really slow rendering times you're seeing with the remote data are
akin to
the problems my app is having with partial updates of the loaded SVG
document??
Any thoughts, Thomas?
thanks,
Scott Ruffner
---------------------------------------------------------------------
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]
