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.

oh, yes - I overread that that patch is for dynamic files only.

but, as you told me - I added a script tag to the static file that does nothing and rendering went to less than three seconds compared to the previous 15 seconds. So, thats much, much better now.

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.

In the Yosemite map I use symbols, markers. I don't use patterns, filters and masks. There is a filter definition in the <defs> section, but it is never applied in Batik. I only use it in ASV, due to a bug with line-widths on text elements. In ASV I use a filter to produce "halo" effects around the text elements, but they aren't used in Batik.

The interesting thing with the Yosemite mapping application is, that the initial map loads and renders quickly (5-10 seconds), but takes awfully long (several minutes) to render the data received by getURL(). So I suspect, something weird is going on when rendering the geometry received by getURL() on MacOSX. Maybe this fact helps you with the investigations.

   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.

no, I don't use the static attribute, and I did not test with a 'static-patched' Squiggle on MacOSX. The only patch I applied is the "macosx-render.patch".

Andreas

--
----------------------------------------------
Andreas Neumann - Institute of Cartography
Swiss Federal Institute of Technology (ETH)
ETH Hoenggerberg
CH-8093  Zurich, Switzerland
Phone: ++41-1-633 3031, Fax: ++41-1-633 1153
e-mail: [EMAIL PROTECTED]
www: http://www.carto.net/neumann/
SVG.Open: http://www.svgopen.org/
Carto.net: http://www.carto.net/


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to