ESRI dynamic display…some limitations

Recently I was working on a portion of a large ArcEngine development project in which we had requirements to draw a large number of point features in the map at changeable time intervals as short as ½ second in such a way as to avoid the map flashing or blinking at the user.  A brief look out on the ESRI site pointed me to the IDynamicMap interface and a pretty comprehensive example of how to use the dynamic map to rapidly render dynamic features.  There’s a whole nifty little dynamic display API that supports rendering in this environment.So off I went, charging down that alley and I subsequently bothered to carefully read the “destructions” as well as the limitations page describing what the tradeoffs are that you make when using it.  The two biggies that stood out immediately were the diminished rendering quality and the lack of support for labeling/annotation.  Sacrificing map quality and labeling for speed makes sense on an intellectual level , but wasn’t going to make the client happy because the maps that were being published for consumption by ArcEngine featured labels and annotation as a prominent part of the map content and the user base wasn’t going to accept funky looking maps.  Several other things that weren’t on the list reared their ugly heads only after I’d done some development and testing and were even bigger deal breakers for me…just thought I’d call them out here in case anyone else is evaluating this approach.

 First, when you cast an IMap to an IDynamicMap, it is veeeeeerrry time consuming.  On a dual core laptop with 4GB RAM, we’re talking time scales of several seconds and because of the market we were developing for, I knew the end users weren’t likely to be blessed with even that level of hardware. Second, if you have in memory feature layers, which I did, those go away as well.  Imagine my consternation when I turned on the IDynamicMap  functionality and watched in surprise as my dynamic points moved around the screen as designed while 4 critical map layers disappeared!  A third issue I ran into was the rendering quality of the point symbology itself.   And really the diminished rendering quality was worse than I would have thought.  Project requirements dictated that high res, web 2.0 style icons with lots of color depth and detail be rendered for most dynamic point features yet when we did things like map rotation, we got pretty severe color flattening (shades of red all became the same red beyond what you’d expect for a 32 bit display) and some odd dropped or missing pixels resulting in “speckle” in the icons…no good.

 Clearly in my case, the familiar and comfortable old IFeatureLayer and IFeatureClass weren’t going to do it in light of performance and rendering requirements.  What I really needed was a Feature Graphic like you get in AG Server where the graphic element in the map can be associated with tabular information.

Well, there was a lot of hand wringing at this point, discussion of OpenGL and a couple of other options, but I wound up just rolling my own GDI+ solution.  Essentially we used double buffering to mitigate flashing of the map, creating a base class to handle the drawing and logic of translating between graphic and map space.  Each implementation class for each point type held data (essentially an DataRow from a SQL database) and icon information that would be used by the base classes drawing routines.  The added advantage to this approach was that we didn’t need to force a map redraw while dealing with dynamic feature location rendering.  Finally, this also allowed us to do some fancy mouse hover stuff to display point attribute information as well.  The lesson here?  Always read the “destructions”…and roll your own if you need to.