[mapguide-internals] RFC 38 - GETDYNAMICMAPOVERLAY EnhancementsforSelection

[Jason Birch]

Having thought about it a bit, one thing that concerns me about this
proposal is that much of the apparent performance of MapGuide web apps
is now determined by the speed of the user's connection, primarily
because of the size of the images.

Is there any way that the selection-only image could be rendered with a
smaller bit-depth, and still have an alpha channel for decent rendering?

I do realize that there will be performance benefits when users are not
modifying their extents and doing multiple selections.  I guess the
client could also be smart enough not to request the selection layer
when there is nothing in the selection?  What would the API do when
called on a null selection?  Return an HTTP error, or a big transparent
image?

As far as selection colour goes...  I would like to see a more robust
option for selection style than just colour :)  Border width, border
style, border colour, fill pattern, fill colour, labelexpression,
labelstyle.  Yeah, I know I'm asking for too much...

Jason

-----Original Message-----
From: Haris Kurtagic
Subject: RE: [mapguide-internals] RFC 38 - GETDYNAMICMAPOVERLAY
EnhancementsforSelection

Hi Trevor,

Perhaps obvious from enumerator names but (I think it could be better if
that would be written in RFC) If BEHAVIOR is RenderSelection than
returned image is selection only?
If BEHAVIOR  is RenderSelection||KeepSelection than selection is stored
and will be returned on next get ?
When rendering (pan,zoom,..) viewer will use two requests (on for image
one for selection) instead of one request (if KeepSelection is not set)
?

While doing this change is it wise to add a parameter for color of
selection.

Haris