GDI+ Performance

[Farabi]

Anyone did code timing to GDI+? How is it compared to GDI?

[Jimg]

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.

[Farabi]

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?

[Jimg]

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.

[Farabi]

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.

[jj2007]

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.

> I added a gdiFlush after each test to try to get better timings.
That does not prevent background execution problems?

MSDN: 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?

[Jimg]

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!