Hi Gabriel,
I have been looking at geoserver's svg rendering as per http://jira.codehaus.org/browse/GEOS-400
I tracked the problem down to GetMapResponse. There are two methods of interest:
execute(Request), and writeTo(Request).
The GetMapResponse releases resources of the MapContext (MapContext#clearLayerList()) at the end of the execute() method, which means that when the SVGMapProducer doesn't have any layers to render in the writeTo() method.
I changed it so that the resources arent released until the end of the writeTo() method, which is the end of the requests life cycle.
The change is pretty simple but i thought I would run it by you first since the devil is often in the details.
On another note, I created another GetMapProducer that produces svg using batik instead of the render that you wrote. The bad news is it is slow (no suprise), however it does all the styling.
So we have a couple of options:
1. Only use one of working renders, or
2. Use both, and make it part of the WMS configuration which one to use.
Any thoughts?
--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org
Hi Justin,
looks good.
I don't remember what the cause was for the memory leak problem involving
clearLayerList(), though I'm aware the problem existed and that was the
solution.
By the way, I was investigating a way of streaming Batik, and looks like we
could be able to get an in-the-middle solution. I mean, writing a subclass of
Batik's AbstractGraphics2D that instead of making a DOM grow up indefinitelly
just writes up xml to an outputstream in an element by element basis.
So my plan is first getting that working, then minimizing the verbosity of
generated svg by replacing by-element styling with CSS and class= attributes.
This would give us a much more memory friendly svg producer with full styling,
though I don't think I'll have time to dig into it until weekend.
cheers,
Gabriel.
On Tuesday 18 October 2005 07:11, Justin Deoliveira wrote:
Hi Gabriel,
I have been looking at geoserver's svg rendering as per
http://jira.codehaus.org/browse/GEOS-400
I tracked the problem down to GetMapResponse. There are two methods of
interest:
execute(Request), and writeTo(Request).
The GetMapResponse releases resources of the MapContext
(MapContext#clearLayerList()) at the end of the execute() method, which
means that when the SVGMapProducer doesn't have any layers to render in
the writeTo() method.
I changed it so that the resources arent released until the end of the
writeTo() method, which is the end of the requests life cycle.
The change is pretty simple but i thought I would run it by you first
since the devil is often in the details.
On another note, I created another GetMapProducer that produces svg
using batik instead of the render that you wrote. The bad news is it is
slow (no suprise), however it does all the styling.
So we have a couple of options:
1. Only use one of working renders, or
2. Use both, and make it part of the WMS configuration which one to use.
Any thoughts?
Hi Gabriel,
Sounds good, I will commit my fix.
I think for now I will setup a configuration option on the WMS page to allow users to switch between the two renderers. Once you have the streaming svg renderer up and running, we can switch over to it and have a single svg renderer.
-Justin
Gabriel Roldán wrote:
Hi Justin,
looks good.
I don't remember what the cause was for the memory leak problem involving clearLayerList(), though I'm aware the problem existed and that was the solution.
By the way, I was investigating a way of streaming Batik, and looks like we could be able to get an in-the-middle solution. I mean, writing a subclass of Batik's AbstractGraphics2D that instead of making a DOM grow up indefinitelly just writes up xml to an outputstream in an element by element basis.
So my plan is first getting that working, then minimizing the verbosity of generated svg by replacing by-element styling with CSS and class= attributes.
This would give us a much more memory friendly svg producer with full styling,
though I don't think I'll have time to dig into it until weekend.
cheers,
Gabriel.
On Tuesday 18 October 2005 07:11, Justin Deoliveira wrote:
Hi Gabriel,
I have been looking at geoserver's svg rendering as per
http://jira.codehaus.org/browse/GEOS-400
I tracked the problem down to GetMapResponse. There are two methods of
interest:
execute(Request), and writeTo(Request).
The GetMapResponse releases resources of the MapContext
(MapContext#clearLayerList()) at the end of the execute() method, which
means that when the SVGMapProducer doesn't have any layers to render in
the writeTo() method.
I changed it so that the resources arent released until the end of the
writeTo() method, which is the end of the requests life cycle.
The change is pretty simple but i thought I would run it by you first
since the devil is often in the details.
On another note, I created another GetMapProducer that produces svg
using batik instead of the render that you wrote. The bad news is it is
slow (no suprise), however it does all the styling.
So we have a couple of options:
1. Only use one of working renders, or
2. Use both, and make it part of the WMS configuration which one to use.
Any thoughts?
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org