Changes between Version 9 and Version 10 of MapGuideRfc60

Timestamp:

04/16/09 16:52:47 (16 years ago)

Author:

uvlite

Comment:

moved color collection into VectorScaleRange object

MapGuideRfc60

@@ -61 +61 @@
 The interesting task is how to feed the base colors of the map to the Image Renderer making the image.
 The base colors of a map can be extracted most efficiently during map generation in MapingUtil::StylizeLayers().
-To do this the VectorLayerDefiniton gets an additional method called VectorLayerDefiniton::ComputeUsedColors(scaleRange).
-At the end of the stylization this method is called and the resulting color list is stored in the runtime map object MgMap.
-(Map->SetColorPalette(pStringColorList))
+To do this the VectorScaleRange gets an additional method called VectorScaleRange::GetUsedColorList().
+This is a computed property implemented as a singleton which creates the list upon access. Subsequent requests from other threads read the same list. 
+At the end of the stylization GetUsedColorList is called and the resulting color list is stored in the runtime map object MgMap.
+(Map->SetColorPalette(pStringColorList)) This method sorts and uniquifies the color list upon storage.
 
-The RenderingService reads the color list from the map object, sorts and uniquifies it, and converts it into a more appropriate Colortype.
+The colors from the MdfMModel are MdfStrings and the algorithm simply collects all different strings. So in order to support expressions for those colors the list simply needs to be interpreted when read from the MgMap object.
+
+The RenderingService reads the color list from the map object, and converts it into a list of RsColor objects.
 This color palette is then passed down via the AGGRenderer to the AGGImageIO objects Save method. Here the png color quantification 
 algorithm is included to force the provided palette into the rendered image - this way making sure that the correct base colors survive the compression and/or color quantization.
@@ -72 +75 @@
 == Implications ==
 
-No Implications are intended as this behaviour is desired by default. We just get better looking maps. The cost of extracting the colors from the in-memory representation of the XML data describing the map are presumed to be negligable.
+No Implications are intended as this behaviour is desired by default. We just get better looking maps. The cost of extracting the colors from the in-memory representation of the XML data describing the map are presumed to be negligable. However, the color quantification can be costly.
 
 == Test Plan ==
@@ -108 +111 @@
 5. Possible memory issues: I think the current approach follows an easy producer consumer style regarding the color tables. [[BR]] 
 My insight into the server architecture is limited and I am not 100% sure if all possible memory leaks have been avoided.
+
+6. The algorithm parsing the MdfModel simply collects all different MdfStrings from the color fields. In order to support expressions for those colors the list simply needs to be reinterpreted when read from the MgMap object. Lacking useful test cases this has not been done as yet.