ThinkGeo.com    |     Documentation    |     Premium Support

WPF Far Slower than WinForms

#1

We have a demo application we wrote internally for Vehicle Tracking.  It is a Desktop WinForms App.  It uses the OsmWorldMapKitLayer Project and the latest SQLite Database.  We are mapping about 20 trucks right now as features.  The Winform version has been slow when moving the map or zooming out.



So as a comparison we wrote a WPF version of the Demo application today.  Basically the same code only using the WPF version of the control.  This version is easily 10 times slower or more.  It takes a good 45seconds or more to show all of the tiles.  Then when I zoom or move the map, it takes 45seconds or more again to repaint the tiles.  I am shocked the WPF is so much slower than the Winforms version.



Does this seem right?  How would we go about looking for performance issues?  I know that may be hard to say without seeing our code.  I am willing to send you code or create a proof of concept app to test.  We use DevExpress for our control suite so I cannot send you the application as it stands.  Just looking for some guidance.  We are very concerned about both the WinForm and WPF performance and cannot see a customer ever using a product that is this slow.

#2

Hi Dave, 
  
 Thanks for let us know your requirement. 
  
 Because the map is in your products, so that maybe caused by many reason. I only have some suggestion about how to find the reason of why it’s so slow. 
  
 1. Try to put map related code in a simple WPF project without DevExpress, I think DevExpress should mainly provide some UI feature but not related with map function. This is for exclude the control conflict reason. 
  
 2. If your product is Vehicle Tracking, I think that meant contains two parts: One is for moving trucks, they should get refresh frequently. The other is base map, it maybe contains network tiles, local tiles or some raster layers. I don’t think that’s related with moving trucks, because you should put them in some layer like InmemoryFeatureLayer, so if possible, please disable that first and see whether the speed is still so slow. 
  
 3. If the problem is come from base map, that maybe mean the render speed is slow if you hadn’t opened the tile cache. Here we can use some property like DrawingTime to know which layer render slow, so we can try to improve them. 
  
 Because the render is different between desktop and WPF, so I cannot guess what’t the problem, after find the reason we can talk about how to solve it. 
  
 Wish that’s helpful. 
  
 Regards, 
  
 Don

#3

Thanks Don.  I will try all of these and report back with my findings. Last evening I had considered making a straight WPF project without the DevExpress suite and skins to see if it had an effect.

#4

Don, I removed all the Devexpress components and went straight WPF.  I have checked and we are only refreshing the Vehicle Layer in our timer tick. The Vehicle Layer is a Layer Overlay that holds all of the InMemoryFeatureLayer(s) that represent each truck. 
  
 It is still very very slow in fact un-usable.  We are using the same code for the desktop which is also a little slow but not as bad as WPF. 
  
 Not sure how to proceed.  The performance if killing us and my boss is starting to re-think using ThinkGeo because of this.  What can we do to determine why our demo app is so slow?

#5

Hi Dave, 
  
 Thanks for your effort on this problem and I am sorry to hear the WPF don’t works so well in your project. 
  
 Today I talked with our developers, we hadn’t found any possible issue to cause so big performance issue, because generally the WPF version can works faster than desktop version. 
  
 If possible please sent your straight project so we can quickly help you locate the issue, you can remove all private code in it, and you can directly sent us by email but not upload here. If you cannot do that, please sent us the map load related code, maybe we cannot exactly find the problem only from code, but I think our experience maybe helpful here. 
  
 And we have a Vehicle Tracking sample for WPF, you can download it in our product center or wiki, please try to run it and see whether that works well in your environment. And maybe compare the code is also helpful. 
  
 We are very want to help you solve this issue. 
  
 Regards, 
  
 Don

#6

Don, we emailed you the demo project this morning.  I hope this will help.

#7

Hi Dave, 
  
 Thanks for your sample, I am downloading the latest sqlite database for test your issue. 
  
 If I get any process on it or have any question I will update here. 
  
 Regards, 
  
 Don

#8

Hi Dave, 
  
 I am sorry we don’t have news on it, and we will go on working for it the next workday. 
  
 Regards, 
  
 Don

#9

That is OK Don.  I know you guys at ThinkGeo are busy too.  I am working with Peter also on some routing issues so I have many pieces to keep me busy today.

#10

Hi Dave,



I checked your project and the codes look fine. But I can’t make the project running without your sql server database (gps_demo15). Do you mind to send your database to us also?  Just piece of records would be fine. 



Looking though your project, I find there are a lots of base map like Bing,Google,etc. ,Does the bad performance only happen on the OSMWorldMapKit layer with Sqlite? I want to make sure whether this issue is caused by Sqlite layer. I tested our latest sqlite extension individually and looks like the performance in WPF is fine. Here is a test video.  screencast.com/t/u6Ro3Fs8Fgv



Thanks,



Troy




#11

Dave,



Saw your posting here so thought I’d let you know that I use Wpf and also incorporated a tracking layer and really don’t have any issues with the tracking itself.  I’m tracking roughly 1000 features and process 2.5 million updates to those feature per day.  I’m using an InMemoryFeatureLayer for the tracking.  Panning the map is fine, zoom in/out can sometimes take more time than I’d like, but it’s not affected by the tracking layer.



Regards,

Dennis


#12

Thanks For the Info Dennis.  The tracking layers seem to work fine.  All of the features seem to move well.  It really is the Panning, zoom, and dragging of the map that takes very long to draw.  For internal use I wouldn’t care but in a product we will sell to clients the performance isn’t acceptable.  This will certainly be panning and zooming for sure.



Thanks again for the feed back.

#13

Troy, I know I own you an answer from your post.  I will get you some answers in a day or so.  I had to jump on another project.

#14

Thanks Dennis.

Dave, feel free to post here, we will be watching on this.



Thanks,



Troy