Changes between Version 10 and Version 11 of MapGuideRfc60


Ignore:
Timestamp:
Apr 28, 2009, 2:06:16 AM (15 years ago)
Author:
uvlite
Comment:

closed known issues

Legend:

Unmodified
Added
Removed
Modified

  • MapGuideRfc60

    v10 v11  
    6262The base colors of a map can be extracted most efficiently during map generation in MapingUtil::StylizeLayers().
    6363To do this the VectorScaleRange gets an additional method called VectorScaleRange::GetUsedColorList().
    64 This is a computed property implemented as a singleton which creates the list upon access. Subsequent requests from other threads read the same list.
     64This is a computed property implemented as a singleton which creates the list upon access. Subsequent requests from other threads read the same list. The singleton is not protected with a mutex as a second thread would recreated the same datastructure....in the worst case I can imagine a few kBytes of memory leak with a very low probability.... more costly than the mutex I suppose.
     65
    6566At the end of the stylization GetUsedColorList is called and the resulting color list is stored in the runtime map object MgMap.
    6667(Map->SetColorPalette(pStringColorList)) This method sorts and uniquifies the color list upon storage.
    … …  
    7576== Implications ==
    7677
    77 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.
     78No 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 is a bit more costly.
    7879
    7980== Test Plan ==
    … …  
    9495== closed Issues ==
    9596
    96 No user stored palettes are used in this approach as the colors are defined in the map & layer definitions. The whole idea of providing the colors in an external file has been dropped as its more consistent and also fairly easy to create another version of the map having  other colors defined within.
     971. No user stored palettes are used in this approach as the colors are defined in the map & layer definitions. The whole idea of providing the colors in an external file has been dropped as its more consistent and also fairly easy to create another version of the map having  other colors defined within.
    9798Supplying an user specified color palette to override the colors specified in the map fails at the missing mapping from a linear color list to the complex hierarchical structure of the map definition.
    9899
    99 == open Issues ==
     1002. The quantization algorithm can use quite some memory. 3 different memory allocation schemes have been provided. [[BR]]
     101Due to recent problems in low memory situations a choice has been made to use the most conservative stack based allocation scheme.
    100102
    101 1. The quantization algorithm uses quite some memory. 3 different memory allocation schemes have been provided. Selecting those is supposedly too specific to warrant a server option entry. [[BR]]
    102 However, the correct approach needs to be decided by a system architect with deeper insight into the MapGuide server architecture.
     1033. In this phase only the colors from the VectorLayerDefinitions and in there the Area, Line, and Point Symbolizations are parsed
     104as cleartext. Any further evaluation requires resource lookups which are a higher order of complexity and should not be permanently enabled.
    103105
    104 2. Is it sufficient to scan the colors from only the VectorLayerDefinitions and in there the Area, Line, and Point Symbolizations ?
     1064. No more memory issues. After some problems the code has been changed to duplicate any data from the MdfModel. Now the objects are created after stylization and destroyed after the tile has been created.
    105107
    106 3. How do we deal with color expressions? Are there some specs for this? [[BR]]
    107 The current code is based on the existing XML schemas only (and the color definitions I could find in them)
    108 
    109 4. Following ResourceId references is also not implemented. Is this crucial?
    110 
    111 5. Possible memory issues: I think the current approach follows an easy producer consumer style regarding the color tables. [[BR]]
    112 My insight into the server architecture is limited and I am not 100% sure if all possible memory leaks have been avoided.
    113 
    114 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.
     1085. The algorithm parsing the MdfModel 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. Like the resource lookup this can be added at a later point in time when test cases and clearer specs have been established.