ThinkGeo.com    |     Documentation    |     Premium Support

General map control performance

#1


Sometimes I feel somewhat disappointed with the map control rendering performance.


Even with simple shapefiles the performance is not so good as I expected. I'm rewriting a map software using the WPF map control, and the performance is much much slower than the old app, which was written in VB6, several years ago. I was expecting to have a performance boost using the WPF map instead of the WinForm map, but it didn't happen. I'd be like a heaven to have the performance that ArcView or the ArcExplorer (written in Java) have, for instance. They are extremely fast.


I have some big shapefiles, that I'll probably have to split in several .shp based on the zoom level some feature should appear, otherwise it'll be impossible to use the app. Sometimes, I get afraid of continuing using MapSuite and at some point during the development I get stuck due to a performance issue. It can't take more than one second (or half a second) to pan and zoom the map, or it will be unacceptable in terms of user expectancy.


What can I expect in this scenario? What should I do to improve the performance? I know I can use tile caching but I can't count on that, it's an option to the user.


Thanks




#2

Gustavo, 
  
 Thanks for your post. 
  
 I agree with you that the WPF map control is a bit slower than expected, the root reason is that the WPF map control up to now is not a native WPF control. We just wrap it into a wpf version; its basic drawing logic is still within GDI+.  
  
 Now we are developing a new wpf control and its performance is much better than current version, and is compatible or even better than current Winforms version. While unfortunately, the new WPF control will be delayed to be published for some reason. Hope it can be ready and published within this month. 
  
 Thanks. 
  
 Yale 


#3

That's really great news, Yale. I'm looking forward to it. I'd appreciate to be in touch with it during its beta stage.


For now, I'll downgrade to the winform control version. I don't want to develop my app in winforms, so, as many desktop mapsuite developers, I suppose, that is a really an expected feature.



#4

Gustavo, 
  
 I think for easy to use and to avoid breaking change, the new WPF control has almost exactly same APIs with current WPF control. 
  
 I guess it will be releasing in the coming days with Beta version. 
  
 Any more questions just feel free to let us know. 
  
 Thanks. 
  
 Yale 


#5

Hi Yale, 


any news about the WPF Control performance in beta stage?



#6

Gustavo, 
  
 Thanks for your interests.  
  
 Please contact our support(support@thinkgeo.com) to ask for a Eval new WPF control product if you are interested. 
  
 Thanks. 
  
 Yale 


#7

I did that Yale, and they suggested me to download the 4.0.28 .dll version?


Does this version really include this perfomance enhacement?



#8

Gustavo, 
  
 I am sorry maybe we misunderstood in some place. The performance was greatly enhanced in the new product called “Map Suite WPF Desktop Edition”, the zip package probably is “WpfDesktopEditionFull4.0.28.0.zip”, it is not the original Desktop Edition package. In this new package, it only contains the WPF map control, which is an native WPF control. 
  
 Sorry for the misunderstanding. 
  
 Any more questions just feel free to let me know. 
  
 Thanks. 
  
 Yale 


#9

Gustavo, 
  
 When I first started using the MapSuite I too had performance issues.  In re-reading the Getting Started and other examples I found that my problem was that I had not opened my shapefiles specifying an index.  Once I did this, things really speeded up. 
  
 Hopefully this helps. 
  
 Elisa

#10

Elisa, Thanks for your experience sharing, I appreciate it very much. 
  
 I think now Gustavo’ frustrating thing is our support may have given him the wrong product as we expected. 
  
 Any more questions just feel free to let me know. 
  
 Thanks. 
  
 Yale 


#11

Sorry, I’m curious about winformsMap and WPF which performance is better? 
 Because I do not have test environment can use WPF, so I hope someone can give me the test data/results. 
  
 winformsMap’s load time still doesn’t speed up enough. Especially in version 4.0, the load time much more than version 3.x.

#12

Carol, 



Sorry for the messing up, let me clear it up. 



Up to now, we release our Desktop Edition product which contains both the Winforms and Wpf version, unfortunately the WPF version is not a native WPF control which affects the performance quite a bit. 



Now we are on the end of a new WPF product which is an native WPF map control, we are now doing multiple tests against it and it is expected to be released to beta stage in the coming weeks. 



Anything I am not clear just feel free to let me know. 



Thanks. 



Yale 

 



#13

Apparently, the new WpfMap control has a nice performance compared to the old version. That’s exciting.  
  
 I have some questions, though. 
  
 First, will it be possible to upgrade from the DesktopEdition to the WpfDesktopEdition for free? We are purchasing the DesktopEdition, but we want to develop in Wpf, so it’s important to know if this upgrade is possible without any extra charge, or if we should buy the WpfDesktopEdition directly when it’s available. 
  
 Second, is there a date to the WpfDesktopEdition be released? 
  
 Third, is the new WpfMap control fully compatible with the old WpfMap control? I mean that because there wasn’t a property called ZoomLevelSet in the new WpfMap control. Maybe the property changed its name and behavior to ClientZoomLevelScales, but can we expect that everything that was possible using the old WpfMap and the WinformsMap controls to be accomplished using the new WpfMap control? 
  


#14

For your first two questions, I recommend you contact your sales representative for the exact answers. 
 For the third question, the new Wpf Map control is a seperate product from the old one with no full compatibility. Everything that could be done with the old product should be acomplishable with the new product but maybe with the a different API name. So, ZoomLevelSet is now ZoomLevelScales.