ThinkGeo.com    |     Documentation    |     Premium Support

DrawingVisual vs GDI RenderMode

Greetings,


I am testing out the new WPF control, and have got my basic map up and rendering.  My problem is when I set it to render using DrawingVisual, it basically just sits there using all my CPU and does nothing for a very long time.  If I switch it to GDI, it renders way faster.  It is my understanding that DrawingVisual is supposed to be higher performance than GDI, so I'm unsure if I'm doing something wrong.  Thanks for your help,


 


.Ryan.



Hi Ryan, 
  
 Yes, I agree with you that DrawingVisual has higher performance than GDI+ and it has more advantage in the WPF. 
  
 In WPF Desktop Edition, drawing with GDI+ and DrawingVisual has a little different mechanism; when drawing with GDI+, it draws in a different thread which means it doesn’t affect your operations such as panning and zooming during drawing. While DrawingVisual draws synchronize which means you cannot pan while drawing. So it causes the effect the higher CPU usage and not responds for a short time. 
  
 We recommend using GDI+ if the shape data is too big recently with this beta; and use cache to get better performance. On another hand, we’ll try our best to enhance the DrawingVisual performance later. When the shape data is not too big, we recommend using DrawingVisual which will give better response such as tracking a line on the map. 
  
 Thank you for evaluating the WPF Desktop Edition and please feel free to let us know if you have more queries. 
  
 Thanks, 
 Howard

Ryan, 
  
   The Drawing Visual draws directly to the screen and is not really cached.  The main advantage is for high resolution scenarios where you have alotl of movement or low number of shapes to draw.  When using GDI+ we draw on a bitmap and then display the bitmap.  When resolution are high such as over 2000x2000 then creating the bitmap and displaying it takes time.  In these cases doing the direct drawing is much faster.   A good example would shape editing or track shape drawing at high resolutions.  In these cases the refresh rate of the features needs to be high and but the overall number of features is low.  It is the same for all of the InteractiveOverlays, they benefit from the DrawingVisual.  Another example is if you had a few thousand points that refreshed very often.  In high resolution scenario the overall refresh rate of this overlay would be much higher.  The best way to see it is looking at the track zoom at high resolution, before drawing visual as you draw the rectangle the screen had to refresh the entire image.  Now we can use the drawing visual and the performance is much faster.   
  
 David

David,


Thanks for your reply.  Just to give you a better idea of what I am seeing, I have timed the drawing of my two overlays, and got the following:


Edit: I turned off caching for this test, so caching is not giving me any speed using GDI


GDI:


Overlay1: 00:00:00.0625004

Overlay2: 00:00:00.0156251


DrawingVisual:


Overlay1: 00:00:13.0157083

Overlay2: 00:00:12.2813286


 


Also of note, there should be no data visible at my current zoom level in Overlay2, so the 12 seconds to draw that overlay does not seem correct.


 


Thanks,


.Ryan.



Ryan,



As my last reply mentioned; DrawingVisual and GDI+ rendering are different recently. Using DrawingVisual is rendered synchronously while using GDI+ is rendered asynchronously. So the result you post here is not quite accuracy as I thought. Because the result of GDI+ in your result is just collect some information but cannot indicate the actual rendering time. Because of GdiPlus RenderMode is rendering asynchronously and it doesn't affect the panning operation so you didn't feel slow.



As I tested with the county data, here is my result which shows DrawingVisual renders a little bit faster than GDI+.



DrawingVisual

Index     Elapsed(ms)

1              39

2              30

3              29

4              31

5              55



---------------------

GDI+

Index    Elapsed(ms)

1              53

2              58

3              62

4              23

5              56




It will be great that you can send us your test data so that I can get the real drawing time on my side. On the other hand, we can plan the async rendering for DrawingVisual in the future.



Thanks,

Howard



Hi Howard,


I got those times on the first time my data was rendered using OverlayDrawing and OverlayDrawn events, so there was no panning.  The thing that confuses me most is the 2nd overlay which has no data that should be rendered at the zoom level it starts out at, and yet it still took 12 seconds.


.Ryan.



Ryan, 
  
 I think this explains something. Let’s say you have two overlays render on 1280*1024 resolution screen. The two overlays will have 60 tiles in total. The overlay drawing event rises almost at the same time. But the overlay drawn event rises when all of tiles containing in one overlay is drawn completely. In another world, the time from the overlay drawing and drawn is not accuracy because the second overlay’s drawing time in your result may contain drawing time of the first overlay. I recommend using DrawingTile and DrawnTile event instead to track every single tile which gives you the right result I guess. 
  
 On the other hand, I don’t recommend setting every overlay to multi-tile because of the visual tree will be too large. I used to write a pure WPF example that just pan 40 images with their size 512*512pixels outside the map control. The user experience is quite slow in dual screen and even in full screen. So reduce tiles count is one of the way to enhance your user experience. Also, DrawingVisual mode renders synchronously which means it affects the effect of the panning. Try using GdiPlus mode instead recently and we’ll make it enhanced in the future. 
  
 Please try my suggestions and feel free to let me know if you have any more queries. 
  
 Thanks, 
 Howard