GETMAPLEGENDIMAGE should omit empty layer groups from being rendered

[jng]

The current GETMAPLEGENDIMAGE operation has a limitation whereby all layer groups in the current map are included in the rendered legend image.

If the map in question has lots of layer groups but the layers contained within are not visible in the current map view/scale, then this results in a rendered image containing lots of empty layer groups, cluttering up the image.

The GETMAPLEGENDIMAGE operation should be changed to omit empty layer groups from being rendered to the resulting legend image. This was the behaviour in MapGuide 6.5

[tomfukushima]

The code in the patch looks like it will work, but should we be concerned about efficiency? For example, if there are 20 groups and 800 layers in the map then that loop will execute the statement "layer->IsVisible() && layer->GetGroup() == mggroup.p" 20 x 800 = 16,000 times. Should we instead do something like the following...

define Hashtable of groups
for each layer
 if isVisible & !groups.Contains(layer.groupName)
   add the group name to the Hashtable

for each group
 if groups.Contains(group.name)
   execute the code to add group

Now, assuming the hashtable has a good implementation, this might be substantially faster.

[jng]

From a cursory glance of the legend rendering code, it appears that performance is not a function of the map size, rather it is a function of the height of the requested image.

So whether a map has 8 layers or 800 layers, it will render at relatively the same speed given the same image height, since it will only render up to the specified height.

This may become a factor if we're dealing with an large image height (in the 100k/millions of pixels high), but an image of such a height doesn't exactly fall into our standard user scenario (A4-sized printout from AJAX viewer, the only known consumer of GETMAPLEGENDIMAGE)

[brucedechant]

Updated patch to fix memory leak.

[brucedechant]

Fixed. r5162

[brucedechant]

Small update.

r5163