ThinkGeo.com    |     Documentation    |     Premium Support

GDI+ Performance

#1

Hello,


I'm thinking of ways to increase the map rendering performance.


As far as I know, Map Suite is using GDI+ to render the maps. I thought, if GDI+ is hardware accelerated, using a high end graphics card on the server (not a common practice :) ) might make sense.


My searches in the Net didn't come up with a conclusive result. There a lot of myths regarding this and a general consensus that the WPF is the way to go for hardware accelerated graphics and GDI may be extinct in a relatively short time.


Can you comment on this ?


Best regards,


Hakan Çelik



#2

Hakan, 
  
   What an interesting topic and one close to my heart, where to begin…  Be warned I am about to start many sentences with ‘I think’ and ‘I believe’ etc because I am not sure on certain of these points.  It seems hard to nail down credible facts about these technologies.  Their internal implementations can change out form under us at any time and facts at one point in time may not be facts now.  I am going from research I have done over the years with the technologies at various points.  These are all speculations and opinions.  Now that I have that out of the way… 
  
 We do use GDI+ to render maps including those in our WPF Desktop Edition.  I have read various conflicting report as well on if GDI+ is accelerated and to what extent.  It seems that it is however there are many caveats.  First is the notion that GDI+ is a managed wrapper around GDI and as such GDI is reported to have some hardware acceleration associated with it.  The reason, as I understand it, why GDI+ is slower than GDI is that it has allot of safety code baked into is so developers cannot get into issues like with the unmanaged win32 style API.  Having said this, the issue is that you only get hardware acceleration if you render directly to the screen device.  We are rendering to bitmaps for various compositing reason and this is done using the software raster engine.  I do not believe this engine is accelerated.  In our internal tests drawing to the bitmap is faster as it does not have to refresh the screen on every draw.  You will notice that progressive system draw each line or point as it comes in.  While in some way a nice effect it has performance penalties as well.  We have tested large files in our system an ArcView and even though we seem to be the same speed it is hard to really test because the map may look to be finished but it still may be drawing over areas that are already black. 
  
   In regard to WPF the situation is even more strange.  First let me say that WPF is the future of rendering in the .net framework.  I do not think GDI+ or GDI for that matter is getting much love from Microsoft these days.  The problem is that WPF tries to server two masters.  Microsoft needed a drawing system that could provide a markup language such as HTML but also have a speedy drawing API and be very safe and have a hip API.  With the kind of cool layout effects you can get easily with HTML and how hard it is to duplicate in Winforms they had to do something.  It used to be desktop applications looked better and web apps were clunky but with what web designers can do now the desktop applications seem old and outdated.  I think they succeed more on layout issues and didn’t do as well on the speed side.  I think their preference was add the ability of HTML to do markups and flow layout at the expense of the raw speed.   
  
   When we did our internal tests WPF always came up slower than GDI+ across the boards.  We tested with the recommended high speed way to use WPF and still had slow drawing times.  I also think that WPF suffers from non accelerated drawing when using a bitmap as the target.  I also think that even though the performance is bad now Microsoft’s bet is that they can make it better and better over time and that they better get the API and featureset right then worry about premature optimization.  Some proof of this is their addition of the sub pixel shading stuff they came out with awhile back.  I think that WPF uses some Direct X APIs for rendering and they want to use more and more in the future.  How long before they just use Direct X solely?  We have been working on some proof of concepts for a native Direct X version and it is interesting stuff.  It is important to note that we did our testing awhile back when WPF first came out and in fairness we are going back to testing now that it has had a few releases. 
  
   Where does that leave you / us?  Well we now working with some folks to bring more native WPF functionality to the WPF Desktop Edition.  We will be doing more tests and see how the performance is now and weigh the options.  If you are building an application from scratch and want the longest possible shelf life then I would not hesitate to go with WPF over Winforms.  Wait, I can’t believe I just said that as I am a big fan of Winforms but the features of WPF from the forms design view outside the map are compelling.  The good news is as we integrate more WPF functionality will will be conscious to do it seamlessly.  You should not notice the day things might be switched out.  Well I hope you notice a speed increase or something cool 
  
   Now that the rant is over I am almost sure that we can work with you to make your maps draw faster.  There are a number of tips and trick that can really put some zing in your maps.  There is however no silver bullet and each technique has caveats on formats, custom indexes, custom class implementation, cache tolerance, ability to manipulate or split your data etc.  If you are flexible from that side then there are things that can give you noticeable improvements.  If you want to pursue this we can take it off-line so I can get an idea of the results you want and what kinds of data we are dealing with.   
  
   I am interested on your take or anyone else who monitors this forum.  Of course this excludes Brendan as I know he is a WPF nut! :-)  If someone from Microsoft, specifically on the WPF, or GDI+ team, is listening please enlighten us!! 
  
 David

#3

Hello David,


Thanks for the swift response as always. It is nice to know that we are on the same page regarding this aspect of the system.


For the time being, I think it would be better to keep the discussion here for others' reference. If the sitution warrants a closed session with you for confidentialy reasons, I would request it then.


I'm trying to pursue different paths in parallel to maximize the rendering perfomance. Obiously I will use caching but, to be able to cache the map, first I need to render the map. 


Hardware acceleration was one possibilty. The other one is to optimize zoomlevels and visibility of the features according to type, which I'm trying right now. Yet another one is structuring/splitting the shape file, as you have suggested.


For that, there is another topic that I've started. 


gis.thinkgeo.com/Support/DiscussionForums/tabid/143/aff/12/afv/topic/aft/5305/Default.aspx


Can you comment on that ?


Also, I'm using a valustyle to render the roads according to type with at most 10 valueitems. Is there a faster way to do what I like ?


Best regards,


Hakan Çelik


 



#4

Hakan, 
  
   I just posted a reply on the other thread.  The good new is that there are a few simple things you can do to see measurable results.  Let me know what you think. 
  
 David