SetDIBitsToDevice Performance

[johnsa]

Hey all,

So after quite some time I went back to looking at my software rendering work. I decided to remove all the original DirectDraw code as it's really legacy and replace it with something else.
After reading some posts it seems like SetDIBbitstoDevice was the best option (performance wise) from GDI. The other option would be Direct3D texture (which is a lot more work to get setup) and since I'm not going to be using any blending, stretching or fx that I haven't rendered myself into the buffer I don't think it would provide significant performance improvements in the end. Initially before there is a lot of rendering code happening the FPS might be higher, but once the bulk of the work/time is being taken up by actual code the benefits would fall away. So I just wanted to confirm a few things,
A) is SetDIBits the best option?
B) Are there any tricks to get it to run faster - apart from the std stuff like ensuring the bmp format matches etc
C) Here are some frame rate results on my core2 duo 2.0ghz laptop running different sized windows (and fullscreen mode is the same):
   800x600x32 (200fps), 1024x768x32 (200fps), 1280x1024x32 (100fps).... why does it suddenly drop off so significantly for the last mode? (anyone else noticed this ?)

Any info always appreciated.
John

[baltoro]

A while back I stumbled upon this DirectX developer blog, that: Compares Direct2D and GDI
This comparison describes the architecture for Windows7 (you don't say which Windows version you are writing for).   
Also, this is essentially a Windows graphics question,...you'd probably get more relevant information from the MSDN Technical Forums.

[MichaelW]

Assuming that the fps, if not otherwise limited, should be mostly a function of the number of pixels set, the fps for the last mode is not far out of line. Based on the number of pixels the fps for 1280x1024 should be 60% of that for 1024x768, or 120. But why the same fps for 1024x768 and 800x600, when 1024x768 has 64% more pixels?

[oex]

I dont know if this applies to these functions however monitor htz has a similar effect.... Could it be a hardware issue of some description?

[johnsa]

I'm testing this on Windows7. Had a look at the article comparing D2D and GDI. I mean at the end of the day the fps rate of this part will create a theoretical barrier, and in cases when for example the software rasterizer would render something super simple like a cube it might constrain the overall fps that's possible. But in reality, no one is rendering a cube, the rendering process is going to be taking up a much greater percentage of the per-second-time so I don't think 120 or 200fps would be achievable anyway. So it shouldnt really create a bottle neck in a real usage scenario?