🔒 Locked

Blitting speed issue

Started by Soulfire Jan 19, 2004 at 12:49 AM 7 replies 550+ views

Original Post

Jan 19, 2004 at 12:49 AM

While doing a simple test for blitting with colorfills, I ran across something strange. I created a small application that simply draws 2500 squares onto the primary surface every iteration of the main loop, and then a frame counter keeps track and displays the fps. On my system(AMD Athlon XP 2400+, 512MB DDR, ATI Radeon 8500 128MB AGP), I get roughly 68 FPS. If I take out the blitting call to DirectDraw, I get about 40,000 FPS(doing nothing but count frames, of course). So I know that the blitting command is what slows things down(duh.). That isn''t the issue. I tested this application on another computer(AMD Athlon 1900+, 480MB RAM, S3 Graphics ProSavageDDR 32MB PCI!), and this machine got roughly 190FPS! Since it is a slower processor, less RAM, and inferior video card, using the PCI bus to boot, I would expect it''s performance to be worse than my main machine, but instead it is more than double the speed! I am running DirectX 9.0, and the slower machine is 8.1, could that account for the difference? I also ran a test to see if any of the Blt() calls failed for either machine, and all 2500 calls returned as being successfully drawn, so I know the slower machine wasn''t skipping any of the drawing calls. Both machines have DirectDraw Acceleration set to enabled, using the DXDiag tool. I''m completely baffled as to why this is happening. My (supposedly) superior ATI video card (albeit a bit old) draws roughly 170,000 squares per second, while the no-name brand card with 25% the video memory and using the PCI bus instead of AGP gets roughly 475,000 squares per second! Also, I experimented with the size of the squares. Whether the Blt() call was used with a 2x2 square or a 32x32, it did not affect the framerate at all. That would imply that the graphics card itself could handle actually processing the blitting commands and drawing them to the primary surface without any problems. It leads me to believe that the slowdown is in actually issuing those commands to the graphics card. And it would seem to me that it would take a hell of a lot longer to submit 2500 commands all the way through the PCI bus than it would through the AGP bus... Ugh

glassJAw

Jan 19, 2004 at 1:10 AM

Try profiling it on both computers and see where the slowdown occurs.

Also, make sure you have no processor-heavy processes running in the background on either computer.

EDIT: And check to make sure both are running the runtime DirectX libraries.

EDIT2: And you're running a release build of the program.

[edited by - glassJAw on January 19, 2004 2:13:05 AM]

Soulfire

Jan 19, 2004 at 1:20 AM

- As I said above, I know where the slowdown occurs(at the DirectDrawSurface->Blt() call). I just don''t know why.

- There are no processor-intensive applications running on either machine

- As I said above, the fast machine is running DirectX 9.0, and the slower running 8.1.

- I used Dev-C++ to compile the program, I have all debugging options disabled.

Bad Maniac

Jan 19, 2004 at 7:30 AM

This could be as simple as your driver not turning off vsync, so you loose a few frames waiting for vsync and end up on 68 when the vsync is at 75 hz.
It could also be because your new shiny graphics card has little or no support for 2D graphics, so on your PC DDraw resorts to software, or uses a very slow 2D blit in your graphic hardware. While the older PCI card has good support for 2D blitting, thus yields much better performance.

It still sounds very slow though, I''d go over your code with a fine toothed comb. Especially check if your flip call waits for vsync or not.

Metus

Jan 19, 2004 at 10:14 AM

i have the EXACT same problem; my laptop (celeron 1.13ghz + inter i830) renders 1500 tiles (32 * 32) to the backbuffer and flips them to the primary surface with a speed of 49 fps..
my XP1600+ and radeon 9700pro has the speed of 56 only..
at my schools comp, the same app runs at 110fps and that''s a nVidia GF4200 and amd 2200+

i fear that ati don''t gives a sh*t about 2d performance...

James Gregory

Jan 19, 2004 at 10:46 AM

The board is filled with posts on V-sync. Search for some of them.

Metus

Jan 19, 2004 at 10:56 AM

quote:
Original post by James Gregory
The board is filled with posts on V-sync. Search for some of them.

for my problem, i''ve already fixed that...
with no tiles at all, i''ve got 5000+ fps, but as soon as a couple of tiles is blitted, the fps drops instanlty to about 200

falkone

Jan 19, 2004 at 11:39 AM

quote:
Original post by James Gregory
The board is filled with posts on V-sync. Search for some of them.

I seriously doubt that his V-Sync switches between 68 and 40000 during the execution of his program.

Soulfire

Jan 20, 2004 at 12:58 PM

Maybe you guys should read my post again. I said I draw the squares "onto the primary surface". There is no page flipping, and thus no vsync issues. Refresh rate and page flipping are irrelevant in this program.

I did consider that newer graphics cards might put more emphasis on the 3D computing capabilities, and shove 2D to the backburner. This isn''t a life-threatening issue, 60 fps or 2000, it will still run just as good in the end. I was just curious to see if anyone here might have an answer for why this would happen.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.