 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / .NET Framework / New Users / December 2004GDI+ performance issue
I know that's an old dirty issue; GDI+ almost -the slowest part of the framework - has bothered many developers using it in animations. Even in managed C++ the performance is awful. Now, any dude out there does know any thing about this issue in VS 2005 + .NET 2.0 ? Has Microsoft solved this performance problem, or we will have to again stick to that DX for simple animations in our applications? ( and since Microsoft doesn't support DDraw any more, and also because managed DX9 SDK is unimaginable for download -200mb - via modem, we have to really stick to the old DX7, which many users don't have, and which makes our application quiet big in size.) Thank for help Hi, >I know that's an old dirty issue; GDI+ almost -the slowest part of the > framework - has bothered many developers using it in animations. Even in > managed C++ the performance is awful. It doesn't matter what language you use when the bottleneck is within managed library, does it? > Now, any dude out there does know any thing about this issue in VS 2005 + > .NET 2.0 ? Has Microsoft solved this performance problem, or we will have [quoted text clipped - 5 lines] > really stick to the old DX7, which many users don't have, and which makes > our application quiet big in size.) Actually, DX9 redistributable (note *not* SDK as end-user doesn't need SDK) is quite significantly smaller - around 36Mb if I am not mistaken and it is a way to go for animations IMO. And you don't need DDraw - using DirectX3D is actually better and perhaps easier.  SignatureMiha Markic [MVP C#] - RightHand .NET consulting & development SLODUG - Slovene Developer Users Group www.rthand.com > Thank for help They are adding another type of back buffer, that is supposed to be faster for explicit double buffering, and new text drawing functions. I believe that is it. The performance is not awful for simple animations. GDI+ must be used carefully for good performance, it is true, but once you do that, the performance is fine in most cases. It depends how many pixels you are animating at once, and how you optimize the screen updates. Make sure you only redraw the pixels you need to redraw. Regards, Frank Hileman check out VG.net: http://www.vgdotnet.com Animated vector graphics system Integrated Visual Studio .NET graphics editor >I know that's an old dirty issue; GDI+ almost -the slowest part of the > framework - has bothered many developers using it in animations. Even in [quoted text clipped - 9 lines] > our application quiet big in size.) > Thank for help One more thing: they are getting right of expensive calls to Enum.IsDefined throughout System.Drawing, thanks to my complaints. - Frank Actually GDI+ is not part of the framework at all - its an unmanaged library with a thin managed wrapper. Just in case you think that might solve your problem, its also pretty darned slow when called directly from unmanaged code. Cheers Doug Forster >I know that's an old dirty issue; GDI+ almost -the slowest part of the > framework - has bothered many developers using it in animations. Even in [quoted text clipped - 9 lines] > our application quiet big in size.) > Thank for help The base problem is whereas the old GDI was graphics card accelerated GDI+ isn't. The "bonus" is that if you can get acceptable performance, you can get it on any PC. With some knowledge of the system bottlenecks, performance for business type of applications such as charting, diagramming etc can be acceptable. For game type apps and large animations etc, managed DX9 is the recommended route. You seem to be concerned about a DX download/redistributable but keep in mind that most users will also have to download .NET framework redistibutable anyway. James SignatureCreate interactive diagrams and flowcharts with ERM Diagram at http://www.crainiate.net Take the ERM Tour at http://www.flowchartcontrol.com >I know that's an old dirty issue; GDI+ almost -the slowest part of the > framework - has bothered many developers using it in animations. Even in [quoted text clipped - 9 lines] > our application quiet big in size.) > Thank for help The case of supporting GDI+ by hardware is quiet absord. How should i expect my costumers to buy the latest graphic cards (or update their drivers) while the applications with GDI* drawings commonly don't have purposes of their DX counterparts ( like heavy games). No one accepts to do so many system changes for a simple (but neccessary) animation. Besides, i think it is the duty of Microsoft to make thier GDI+ compatible with the common graphic cards of the planet, because GDI+ is a very common technology and more people will use it than DX. > The base problem is whereas the old GDI was graphics card accelerated GDI+ > isn't. The "bonus" is that if you can get acceptable performance, you can [quoted text clipped - 22 lines] >> our application quiet big in size.) >> Thank for help The point James was making is that generally it doesn't matter which graphics card you have, performance is all the same using GDI+. If you can get good performance on one card by knowing the system and recognising where the bottlenecks are you can get that same performance on all cards. AFAIK *only* matrox has a GDI+ acellerated card and I don't even know what model it is. SignatureBob Powell [MVP] Visual C#, System.Drawing Find great Windows Forms articles in Windows Forms Tips and Tricks http://www.bobpowell.net/tipstricks.htm Answer those GDI+ questions with the GDI+ FAQ http://www.bobpowell.net/faqmain.htm All new articles provide code in C# and VB.NET. Subscribe to the RSS feeds provided and never miss a new article. > The case of supporting GDI+ by hardware is quiet absord. How should i expect > my costumers to buy the latest graphic cards (or update their drivers) while [quoted text clipped - 31 lines] > >> our application quiet big in size.) > >> Thank for help The case of supporting GDI+ by hardware is quiet absurd. How should I expect my costumers to buy the latest graphic cards (or update their drivers) while the applications with GDI* drawings commonly don't have purposes of their DX counterparts ( like heavy games). No one accepts to do so many system changes for a simple (but necessary) animation. Besides, I think it is the duty of Microsoft to make their GDI+ compatible with the common graphic cards of the planet, because GDI+ is a very common technology and more people will use it than DX. ( i wonder if they have already done this for their framework....Mac. is the case) > The base problem is whereas the old GDI was graphics card accelerated GDI+ > isn't. The "bonus" is that if you can get acceptable performance, you can [quoted text clipped - 22 lines] >> our application quiet big in size.) >> Thank for help It isn't absurd to support GDI+ in hardware at all. It *isn't* supported by most, which is why it is slow on most machines. If it were supported in hardware, it would be faster. There wouldn't be any change to existing machine's current performance. Times change, and so does technology. Sometimes, in order to move forward, you'll have to sacrifice backwards compatibility. Look at what Apple did with MacOS X, it seems to be working out quite well for them. main(){}; wrote: > The case of supporting GDI+ by hardware is quiet absurd. How should I expect > my costumers to buy the latest graphic cards (or update their drivers) while [quoted text clipped - 33 lines] >>>our application quiet big in size.) >>>Thank for help > It isn't absurd to support GDI+ in hardware at all. It *isn't* supported > by most, which is why it is slow on most machines. If it were supported [quoted text clipped - 4 lines] > forward, you'll have to sacrifice backwards compatibility. Look at what > Apple did with MacOS X, it seems to be working out quite well for them. How many of our customers came crying up until about a year ago about our stuff not working under OS 9? :-) MOST of them believed us when we told them it was a decision Apple made, and that we didn't think it was worth developing backwards, but I know a LOT of people didn't upgrade for years because popular apps wouldn't run under OS X. MS has always made backwards compatibility important to it, rightly or wrongly, and that doesn't look like changing any time soon. Steve Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.