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]
