Andreas Neumann wrote:
I updated to the latest svn version (trunk) and applied the
macosx-render.patch file, using 'patch'.
Unfortunately I don't see any improvements, regarding rendering speed.
The rendering speeds are still very, very slow. I tested with the two
sample maps provided with the Batik distribution:
mapWaadt.svg (contains no raster images and opacity)
mapSpain.svg (contains raster image and opacity)
both take about 15 seconds to render on my machine (see details below).
These are 'static' files so I'm not surprised the time didn't
change. You can trick Batik into thinking they are dynamic by adding
a script element (even if it does nothing). I'd be curious if this
'fixed' the problem for you.
The two files take about three seconds to render on my Linux system (2.2
Ghz, 1.5 GB Ram).
Furthermore I tested with http://www.carto.net/williams/yosemite/index.svg
On MacOSX it takes more than 4 minutes to render (the dynamically loaded
map-data), on Linux it takes less than 10 seconds, including loading,
script execution and getURL stuff. In this application 4 additional map
layers are loaded using getURL.
Gahh! That is horrible. This map should be using the Dynamic renderer
so it is unfortunate that it stays so slow. Does this map use Filters?
Masks? Patterns? I'm just trying to figure out what is causing the
"regression" in performance.
information about my Mac system:
my java-version:
java version "1.4.2_09"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_09-232)
Java HotSpot(TM) Client VM (build 1.4.2-54, mixed mode)
my system:
powerbook G4, 1Ghz, 1GB Ram, MacOSX 10.4.2
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 suspect that mapWaad/Spain is because they are using the old
'static' renderer (if this pans out we may have a MacOSX renderer that
is used for static and dynamic docs). I suspect that something in
the more complex Yosemite document is causing the raster to be
fetched... are you using the 'static' patch? that will cause the
'static' content to be rendered to a 'raster' which will have the
'slow' behavior. I think if you remove any 'batik:static="true"' it
should avoid this.
Scott A. Ruffner wrote:
Thomas DeWeese wrote:
http://issues.apache.org/bugzilla/show_bug.cgi?id=36769
There are some edge cases that I know the new renderer
doesn't handle but I'm curious if it solves the problem
at all or in any kind of useful percentage of the cases.
hi, thomas --
i managed to run a few tests before vacation, and your patch
fixed the rendering performance slowdown that our app
experienced in Mac OSX 10.4.x. here's a summary:
MacOSX Batik "doc" "build" "render"
10.3.x 1.5 354 251 8308
10.3.x 1.6 369 245 675 YEA!
10.4.2 1.6 333 214 13637 DARN!
10.4.2 1.6(patch) 277 133 677 WHEW!
these results are for complete "refreshes" of the entire
document rendered on the JSVGCanvas. unfortunately, when i use the
canvas's
UpdateManager framework to update the rendering in response
to a small change in the SVG document, i will occasionally
get awful rendering times (15 seconds or more) on Mac OSX
that i don't see in Windows. this is probably a different
issue, perhaps thread-related. i'll let you know if i figure
it out...
thanks again for the patch!
scott
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
