The MASM Forum Archive 2004 to 2012

General Forums => The Campus => Topic started by: Farabi on June 03, 2009, 01:56:03 PM

Title: GDI+ Performance
Post by: Farabi on June 03, 2009, 01:56:03 PM
Anyone did code timing to GDI+? How is it compared to GDI?
Title: Re: GDI+ Performance
Post by: Jimg on June 03, 2009, 02:26:55 PM
It's really hard to time because GDI seems to run asynchronously for many operations.

What did you have in mind?  You can mix the two without out problem, they just write to a bitmap.

I'm using GDI when possible, but GDI+ for things like anti-aliased line drawing, loading png's, etc.
Title: Re: GDI+ Performance
Post by: Farabi on June 03, 2009, 03:16:13 PM
Quote from: Jimg on June 03, 2009, 02:26:55 PM
It's really hard to time because GDI seems to run asynchronously for many operations.

What did you have in mind?  You can mix the two without out problem, they just write to a bitmap.

I'm using GDI when possible, but GDI+ for things like anti-aliased line drawing, loading png's, etc.

run asynchronousl? what does it mean?
Title: Re: GDI+ Performance
Post by: Jimg on June 03, 2009, 04:44:15 PM
It means, when you issue a GDI command, the control comes back to the program before the GDI operation is finished.  The GDI operation finishes up in the background as needed, so when timing a call, the stuff that is done later is not included in amount of time between the call and when control is returned to the program.  So, basically, you can't reliably time GDI api calls.  I fought this for a very long time, convincing myself that one operation was faster than another, but ultimately, all the time tests were flawed.  The more repetitions you do, the worse the problem.

The best way is to try it out both ways in a real world application.  Can you tell any difference?

Generally I'd say, if you have to have the absolute fastest, use a dib and put the pixels directly yourself.
Title: Re: GDI+ Performance
Post by: Farabi on June 04, 2009, 08:16:09 PM
Well I guess I will stick with donkeys library for this, just curious about GDI+ speed but it seems no method to know the speed.
Title: Re: GDI+ Performance
Post by: jj2007 on June 04, 2009, 08:24:13 PM
Quote from: Jimg on June 03, 2009, 04:44:15 PMThe GDI operation finishes up in the background as needed, so when timing a call, the stuff that is done later is not included in amount of time between the call and when control is returned to the program.

> I added a gdiFlush after each test to try to get better timings. (http://www.masm32.com/board/index.php?topic=10882.msg79828#msg79828)
That does not prevent background execution problems?

MSDN (http://msdn.microsoft.com/en-us/library/dd144846(VS.85).aspx): In order to completely disable batching, call GdiSetBatchLimit (1) during the initialization of each thread

Now if I interpret that correctly, it means that the current call still may finish in the background. However, if you issue a second short call, set a pixel or similar, the first one should be forced to finish. What do you think?
Title: Re: GDI+ Performance
Post by: Jimg on June 04, 2009, 09:18:22 PM
Even if it were so, and I not saying it is, you wouldn't be testing the execution time in a real world situation.  Background operation is something you have to take into consideration.  The best test, I've found, is to draw an entire frame, everything you are going to do, and measure the total frame time.  The more complex, the better.  Just doing a bitblit isn't going to tell you anything.  You can then dither with individual items and see how it affects the overall time.   By doing this, you will see what makes a difference, and that all the niggling little stuff really has no significant effect.
As Nightware taught me, and I had to finally accept, use a dib and SetDIBitsToDevice.  It tests much slower in any individual, multi repetition standard type time test I could come up with, and it's a pita, but if you use it for it's strengths, direct pixel access, it is much faster in the overall do a full frame test.
Also, much of this stuff is affected by hardware and available memory, so what's fastest on one machine is abysmally slower on another (e.g. my 256m celeron laptop).

But please, don't take my word for it, set up some tests and let us know the results!