vis781
Well-known member
Ok, so here's the thing. There is always a lot of discussion about making calls GDI32.dll over using the framework wrappers for GDI+. So I just wanted to clear a few things up.
Argument.
Using GDI32.dll is slower becuase of the marshalling that takes place from managed to unmanaged code.
Answer.
Completely untrue seeing as GDI+ is unmanaged code it is written in C++. So the same amount of marshalling occurs for calls to GdiPlus.dll or GDI32.dll. Secondly, Microsoft have not written a new Graphics Device Interface in GdiPlus, it is a wrapper for the original GDI32.dll. Yes that's right, any code that calls methods from GdiPlus.dll eventually calls methods in GDI32.dll. The only discernable difference between the two is that GdiPlus is alpha aware and has lots of other fancy methdod that hide the complexity of doing it using plain old Gdi32.
So to my point.. why is it then that things like Graphics.DrawImage is faster than using BitBlt? Well.. it's not, it's slower, infact it's about 1 and a half times slower on my machine, think about it, it would have to be seeing as drawimage uses one of the GDI32 Blt's anyway!! Try it for yourself and see.
Oh and the last thing as far as I know GDI32.dll has the support of hardware acceleration, GdiPlus doesn't, or atleast didn't until the release of Longhorn.
So there you have it. The native framework functions that use GdiPlus are equally as good as using the old GDI32, which one you choose is up to you. We're probably talking nanoseconds here but the thing is you shouldn't feel like you can't touch the old API's if you want to. Oh and just for the record, for things like Graphics.FillRectangle the framework uses Gdi32.dll and doens't go through GdiPlus. There are performance gains to be made if you can comfortably use both .dll's. Don't get me wrong I like GdiPlus, but there are times when all you want to do is draw a border around a region object and GdiPlus can't do it, Gdi32 can and it can do it fast.
Just make sure you apply the correct attribute to all Win32 calls the more information you can give the marshaller the faster it will
execute.
Whilst i'm here let me let you in on another performance tweak in .net. The JIT is clever, i mean really clever and if you have ever browsed the framework and wondered why the hell there are so many different calls to tiny little methods. Well here's the answer.. C++, or any other C style language apart from c# that is, can create a prototype and declare it 'Inline' Inline methods are much faster when used properly and can actually decrease performance when used improperly. What happens is the method body is copied into the calling routine and executed there. The JIT does all this for you but it will not Inline a massive method as it would be counter productive, but it will inline a smaller method call resulting in faster execution. Of course you can go over the top here, don't go mad creating a billion different little methods hoping that they will all be compiled inline. But if you have a significantly large method then break it down into smaller methods, that way the compiler will be much more likely to inline that particular call. The reason this is beneficial is because the JIT will compile the entire method, there could well be parts of that method that aren't used everytime but it will be compiled anyway which has it's performance drawbacks. Imagine now breaking that down into smaller mthods where possible. The JIT will compile the smaller method saving time and inline any methods that, that method may be using that time around.
Argument.
Using GDI32.dll is slower becuase of the marshalling that takes place from managed to unmanaged code.
Answer.
Completely untrue seeing as GDI+ is unmanaged code it is written in C++. So the same amount of marshalling occurs for calls to GdiPlus.dll or GDI32.dll. Secondly, Microsoft have not written a new Graphics Device Interface in GdiPlus, it is a wrapper for the original GDI32.dll. Yes that's right, any code that calls methods from GdiPlus.dll eventually calls methods in GDI32.dll. The only discernable difference between the two is that GdiPlus is alpha aware and has lots of other fancy methdod that hide the complexity of doing it using plain old Gdi32.
So to my point.. why is it then that things like Graphics.DrawImage is faster than using BitBlt? Well.. it's not, it's slower, infact it's about 1 and a half times slower on my machine, think about it, it would have to be seeing as drawimage uses one of the GDI32 Blt's anyway!! Try it for yourself and see.
Oh and the last thing as far as I know GDI32.dll has the support of hardware acceleration, GdiPlus doesn't, or atleast didn't until the release of Longhorn.
So there you have it. The native framework functions that use GdiPlus are equally as good as using the old GDI32, which one you choose is up to you. We're probably talking nanoseconds here but the thing is you shouldn't feel like you can't touch the old API's if you want to. Oh and just for the record, for things like Graphics.FillRectangle the framework uses Gdi32.dll and doens't go through GdiPlus. There are performance gains to be made if you can comfortably use both .dll's. Don't get me wrong I like GdiPlus, but there are times when all you want to do is draw a border around a region object and GdiPlus can't do it, Gdi32 can and it can do it fast.
Just make sure you apply the correct attribute to all Win32 calls the more information you can give the marshaller the faster it will
execute.
Whilst i'm here let me let you in on another performance tweak in .net. The JIT is clever, i mean really clever and if you have ever browsed the framework and wondered why the hell there are so many different calls to tiny little methods. Well here's the answer.. C++, or any other C style language apart from c# that is, can create a prototype and declare it 'Inline' Inline methods are much faster when used properly and can actually decrease performance when used improperly. What happens is the method body is copied into the calling routine and executed there. The JIT does all this for you but it will not Inline a massive method as it would be counter productive, but it will inline a smaller method call resulting in faster execution. Of course you can go over the top here, don't go mad creating a billion different little methods hoping that they will all be compiled inline. But if you have a significantly large method then break it down into smaller methods, that way the compiler will be much more likely to inline that particular call. The reason this is beneficial is because the JIT will compile the entire method, there could well be parts of that method that aren't used everytime but it will be compiled anyway which has it's performance drawbacks. Imagine now breaking that down into smaller mthods where possible. The JIT will compile the smaller method saving time and inline any methods that, that method may be using that time around.
and all tests result that Gdi is and always will be faster to execute so long as it is used correctly of course the test results can also be video card independant depending on how much work GDI has to do before the instructions are sent. The point of this article was to give people who aren't familiar with the win32 API as a whole a nudge. As we all know, in all applications I have developed there are very few times that the framework serves all the requirements.
