ThinkGeo.com    |     Documentation    |     Premium Support

Beta 2.0 Wpf Rendering and Interaction

#1

Hello,


I am using the Wpf Map control from the Map Suite Desktop Edition v3.0.180 Beta 2 and have a question regarding performance and map interaction.


Firstly the continuous rendering of the area you are moving into while paning is a nice feature but seems to render quite slowly.  A reference to the feature I was expecting would be similar to how OpenLayers renders tiles as they are ready to be renderd (i.e. use a blank tile until the actual tile is ready for rendering) I have not tried the pure Win32 map so dont know about ther performance difference between the Win32 and Wpf render but it does feel way to slow.  Is this a known issue to be looked at with the next beta release?  My machine has a Vista OS with AMD TL-52 1.6Ghz with 2Gb DDR2, as such feel my machine has enough power. 


Secondaly the map interaction... In my Wpf application I have canvas controls floating over the Wpf Map but I need to click on the canvas area to take focus away from the Wpf map and then only can I interact with the floating canvas.  As soon as I move my mouse cursor over the Wpf Map it takes focus back and I am again unable to interact with the floating canvas controls unless I click on them again so as to give back focus.  My question is is it possible to have the Wpf Map control to not take focus as soon as I move my mouse cursor over the Wpf Map?  and is it possible to set the Wpf Map control to not accept user interaction at all... That way I can manage user panning and zooming as a work around.  Any other ideas?


Thanks...


Ian McShane 



#2

Ian,


It’s a bug that WPF map gets the focus whenever the mouse cursor is over the map. We will fix it in the next release so when you move the mouse over the wpf map from the floating canvas, the map will not get the focus any more. Thanks for pointing it out and here is a simple demo showing how to work it around with the current version.
 
About the performance issue, could you let me know more about your application, like how many layers in that map and what are the size for them?. Can you just show one layer at a time to see if the low performance is related with the count of layers or the size of the layer? In our test, the WPF application seems not as fast as win32 applications but the performance is not very poor.
 
Thanks,
 
Ben.

336-Post5138_Demo.zip (98.3 KB)

#3

Hello Ben,



In my application I have 3 layers loaded, but by using zoom levels at any one point only 1 of the layers is rendered.  But to be on the safe side I used the solution you provided in your reply and switched the shape file from USStates to one of my base layer shape files.  



First thing I noticed is the panning performance was much the same with either shape file (USStates or mine) so I decided to do further testing using the shape file you provided.  I changed it to have nothing but the WpfMap and the windows size was set to 800x600.



My test was to pan from the top right to the bottom left.  I used the Performance Profiling tool for WPF (windowsclient.net/wpf/perf/wpf-perf-tool.aspx) to capture test data.



From the results I got using the Visual Profiler (see attachment) I noticed that when panning the total CPU usage of the application hits a high of 65.13%.  The cpu usage can be broken down in the following manner:



Application Usage 65.13%

- WpfMap Usage 65.13%

  * UIElement OnRender 43.41%

  * UIElement Layout (Arrange) 21.72%





The WpfMap is a canvas control of which, I assume, uses an image control to render a bitmap which is generated by the class structure.  My thoughts as to why a large hit is made to the cpu for something as simple as panning would be that the Image Control bitmap is continually updated with a whole new bitmap as panning occurs.



This type of change to a wpf control will likely cause the results we see above as the UI element, as far as its concerned, is getting a completely new Visual to render, and as such needs to generate meta data so as to know more about what it needs to render.  This process is in effect asking the WPF Layout System (which is one of the most expensive aspects of rendering) within WPF to evaluate the image control every time a new bitmap is assigned to it causing the performance issue.



It may be possible to reduce the amount of load generated by the Layout System being activated by having an Image property which is updated with the generated bitmap.  This Image property is bound to the Source property on the Image control, that way the Image Control should not cause the Layout System to invoke unless the bounds of the bitmap is different.



In closing, using your solution and your shape file I have pretty much the same performance issue.  From what the WPF Profiling tool is saying, it would seem like the WPF Layout System is being invoked a lot in turn causing the performance degradation.  What are your thoughts?



Ian.



#4

Ian, 
  
 First, thanks very much for letting us know your detail test on this performance issue; that helps us a lot. 
  
 We don’t use the image control you mentioned, instead we use GDI+ to draw the bitmap in memory and then convert it to imageSource render in Wpf control. We found the reason why there are so many layout, that’s because in the MouseMove event, we call the method this.InvalidateVisual() which refreshes the map and also update the layout. So even for a simple operation like panning, it will refresh the layout again and again that degrade the performance a lot. Many places we just follow the pattern of Winforms when developing the WPF control, For example, Invalidate() in Winform is very fast but InvalidateVisual() in WPF will refresh the layout which takes much longer time. There must have some “WPF ways” methods but we didn’t choose the right one. 
  
 Sorry we didn’t spend too much time on this as busy working on the coming release (later this week or early next week). We are still focusing on the winforms control but as main features are added we will focus on the wpf map pretty soon. Then I’m sure we will have a great improvement on WPF.  Thanks again for your message and we will still learn from it. 
  
 Ben.

#5

Ben, 
  
 Thanks for the feedback.  I am looking forward to the next release. 
  
  
 Ian.

#6

Ian, 
  
 We will have a new out tomorrow in which we do not have many WPF enhancements (it mainly work around the cross threading issue). I think the next version will enhance a lot though. 
  
 Thanks, 
  
 Ben.