Graphics performance issues

Ken_Rogoway · July 9, 2004, 5:19pm

We are having problems with the performance of our screen updates on some
video cards. Originally I thought our performance issues had to do with disk
I/O or RAM, but after spending some time profiling last night I found that it
is our display update that is taking a huge amount of time on some cards.

Basically I am keeping a list of surfaces that are “dirty”, copying them to my
screen buffer, and then calling SDL_UpdateRect() for each area that I blitted
to.

I am getting times like 1.5 seconds to redraw the entire screen, and .4
seconds to draw a few dirty rects on the screen. On a system (even an older
one) with a good video card I have no problems.

I am in 800x600x24 full-screen mode. I am not using page flipping.

Some thoughts are:

Video wait states
Waiting for surface Locking and Unlocking.
Possible that using page flipping will help.

I will do more profiling and try some different approaches later tonight, but
wanted to see if anyone else had experienced similar problems and if so what
you did to revolve it.

Thanks!

Ken Rogoway
Homebrew Software

Arrow Antics - Unique puzzle game using SDL
http://www.homebrewsoftware.com/html/arrowantics.htm

Bill_Kendrick · July 9, 2004, 5:23pm

Are your surfaces also 24bpp? If not, SDL will be converting them to it
(e.g., from 16bpp, 8bpp, whatever) every time you blit, which is a major
performance hit.

Sorry if it’s a dumb question

-bill!On Fri, Jul 09, 2004 at 05:19:14PM +0000, Ken Rogoway wrote:

I am getting times like 1.5 seconds to redraw the entire screen, and .4
seconds to draw a few dirty rects on the screen. On a system (even an older
one) with a good video card I have no problems.

I am in 800x600x24 full-screen mode. I am not using page flipping.

Stephane_Marchesin · July 9, 2004, 5:55pm

Ken Rogoway wrote:

We are having problems with the performance of our screen updates on some
video cards. Originally I thought our performance issues had to do with disk
I/O or RAM, but after spending some time profiling last night I found that it
is our display update that is taking a huge amount of time on some cards.

Basically I am keeping a list of surfaces that are “dirty”, copying them to my
screen buffer, and then calling SDL_UpdateRect() for each area that I blitted
to.

I am getting times like 1.5 seconds to redraw the entire screen, and .4
seconds to draw a few dirty rects on the screen. On a system (even an older
one) with a good video card I have no problems.

I am in 800x600x24 full-screen mode. I am not using page flipping.

Some thoughts are:

Video wait states

Waiting for surface Locking and Unlocking.

Possible that using page flipping will help.

I will do more profiling and try some different approaches later tonight, but
wanted to see if anyone else had experienced similar problems and if so what
you did to revolve it.

You don’t tell us much about what you are doing, just about the effects
you see. Please try to describe the situation a bit further, for example :

what OS ?
which SDL backend ?
how big are your surfaces / how many surfaces are you copying ?
what cpu/video card ?
do you have a small program demonstrating your problem ?
…

Stephane

Ken_Rogoway · July 9, 2004, 5:57pm

Bill Kendrick <nbs sonic.net> writes:

Are your surfaces also 24bpp? If not, SDL will be converting them to it
(e.g., from 16bpp, 8bpp, whatever) every time you blit, which is a major
performance hit.
Yes, I create all my surfaces at the same 24 bpp. No conversion is happening
except one time at the initial loading (I create all the images at start-up).

Ken

Ken_Rogoway · July 9, 2004, 6:16pm

Stephane Marchesin <stephane.marchesin wanadoo.fr> writes:

You don’t tell us much about what you are doing, just about the effects
you see. Please try to describe the situation a bit further, for example :

what OS ?
Windows 2000

which SDL backend ?
DirectX

how big are your surfaces / how many surfaces are you copying ?
Main screen is 800x600 so that is the size of the full screen update that is
taking 1.5 seconds. When I just update the changed areas it is 33 rectangles
that are 32x32 pixels each. This takes 300-400 milliseconds.

what cpu/video card ?
This is a Toshiba Satellite 330CDS laptop
CPU is an Intel Pentium 266MHz. 64MB memory installed.
Integrated video card. 2MB card using C&T 65555 chipset.

I realize this is an old machine, but I have had similar reports from newer
machines as well. This happens to be one of the few legacy machines I have
lying around to test on.

do you have a small program demonstrating your problem ?
I will write one this evening.

Bill_Kendrick · July 9, 2004, 6:20pm

Out of curiosity, what flags are you setting when you enable video / open
this window? (e.g., HW surface? Double-buffer?)

http://sdldoc.csn.ul.ie/sdlsetvideomode.php

-bill!On Fri, Jul 09, 2004 at 06:16:57PM +0000, Ken Rogoway wrote:

how big are your surfaces / how many surfaces are you copying ?
Main screen is 800x600 so that is the size of the full screen update that is
taking 1.5 seconds. When I just update the changed areas it is 33 rectangles
that are 32x32 pixels each. This takes 300-400 milliseconds.

Ken_Rogoway · July 9, 2004, 6:37pm

Bill Kendrick <nbs sonic.net> writes:

Out of curiosity, what flags are you setting when you enable video / open
this window? (e.g., HW surface? Double-buffer?)

SDL_SetVideoMode( 800,600,24,SDL_SWSURFACE|SDL_FULLSCREEN );

A guy that is also in the game industry said his company had a lot of problems
running in 24bit mode on some video cards. When they switched to run in 32bit
graphics the performance was fine. I will give that a try tonight and see if
it solves this problem.

Ken

Bill_Kendrick · July 9, 2004, 6:42pm

Yeah, often going to an even byte-depth (16bpp, 32bpp, 8bpp, etc.) can help,
since it’s less akward to copy pixels around. (Computers are good at
moving 1, 2, 4, 8 bytes around at a time, but 3 is a little harder, so
it has to munge a bit. Either that, or 24bpp is just 32bpp with 8 bits
not actually used. In that case, 32bpp might have the same speed issue,
and you might want to try 16bpp, which apparently everyone hates but me )

Good luck!

-bill!On Fri, Jul 09, 2004 at 06:37:02PM +0000, Ken Rogoway wrote:

Bill Kendrick <nbs sonic.net> writes:

Out of curiosity, what flags are you setting when you enable video / open
this window? (e.g., HW surface? Double-buffer?)

SDL_SetVideoMode( 800,600,24,SDL_SWSURFACE|SDL_FULLSCREEN );

A guy that is also in the game industry said his company had a lot
of problems running in 24bit mode on some video cards. When they
switched to run in 32bit graphics the performance was fine. I will
give that a try tonight and see if it solves this problem.

Gabriel_Gambetta · July 9, 2004, 6:48pm

In that case, 32bpp might have the same speed issue, and you might
want
to try 16bpp, which apparently everyone hates but me )

I don’t either. My games use 16bpp and I haven’t heard any complaints.
And it’s faster than 32bpp. Why do people hate it?

--Gabriel> From: Bill Kendrick [mailto:nbs at sonic.net]

Will_McGugan · July 9, 2004, 7:30pm

Yeah, often going to an even byte-depth (16bpp, 32bpp, 8bpp,
etc.) can help,
since it’s less akward to copy pixels around. (Computers are good at
moving 1, 2, 4, 8 bytes around at a time, but 3 is a little harder, so
it has to munge a bit. Either that, or 24bpp is just 32bpp with 8 bits
not actually used. In that case, 32bpp might have the same speed issue,
and you might want to try 16bpp, which apparently everyone hates
but me )

I like to use 32bpp surfaces, since it is much easier to work with. 16bpp is
too much of a hassle for anything but simple blitting, IMHO.

But I’ve found that its the amount of data you push to display memory,
rather than what you are working with in system memory, that is the
bottleneck. Blitting a 32bpp system memory surface on to a 16bpp display
surface is actualy faster than blitting 32bpp to 32bpp!

Will McGugan

Michel_Nolard · July 11, 2004, 10:27am

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Le vendredi 9 Juillet 2004 20:48, Gabriel Gambetta a ?crit :

In that case, 32bpp might have the same speed issue, and you might

want

to try 16bpp, which apparently everyone hates but me )

I don’t either. My games use 16bpp and I haven’t heard any complaints.
And it’s faster than 32bpp. Why do people hate it?

Perhaps because it needs bitwise AND/OR masks to access to each color
component of the pixels in 16 bits, while doing pixels[i*4+1] is simpler to
write in 32bpp…

I think that it simply depends on the nature of the processing you make on the
pixels : per pixels or not.

For my own, I prefer 16 bpp too as too few “Joe Average” computers are enough
powerful to treat huge amounts of graphical data…

–Gabriel

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

Michel Nolard
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA8RYAyAKwOMHoSb0RAho1AJ9RT0mu0DL5h3dyUWXkua25dDxvrQCg3DoK
HbrbKF7PqutFGlcwi1D9lXU=
=qVGa
-----END PGP SIGNATURE-----> > From: Bill Kendrick [mailto:nbs at sonic.net]

jake_b · July 11, 2004, 1:48pm

Using my own code, and another persons code, I’m getting 60 FPS
max for both programs when running in hardwaremode. Even though
mine draws and his doesn’t, and mines a higher resolution, I
still get the same FPS.

Does it max out on Win32 in hardwaremode in fullscreen mode? On
testing I actually got better FPS on software windowed mode than
Hardware mode. (70fps software windowed, 60fps hardware
fullscreen)

Or am I missing something really simple? From searching it looks
like it may be a cause of vsyncing, but it’s supposed to be a
good thing.

Will an openGL backend to SDL give me better FPS? Do I need a
better FPS? Or should I just aim to hit over 30?__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail

Michel_Nolard · July 11, 2004, 1:59pm

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

You are running Windows XP or 2000, aren’t you ?

Le dimanche 11 Juillet 2004 15:48, jake b a ?crit :

Using my own code, and another persons code, I’m getting 60 FPS
max for both programs when running in hardwaremode. Even though
mine draws and his doesn’t, and mines a higher resolution, I
still get the same FPS.

Does it max out on Win32 in hardwaremode in fullscreen mode? On
testing I actually got better FPS on software windowed mode than
Hardware mode. (70fps software windowed, 60fps hardware
fullscreen)

Or am I missing something really simple? From searching it looks
like it may be a cause of vsyncing, but it’s supposed to be a
good thing.

Will an openGL backend to SDL give me better FPS? Do I need a
better FPS? Or should I just aim to hit over 30?

Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

Michel Nolard
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA8UfYyAKwOMHoSb0RAgbGAJ0cRoMOY/WlolIp0dHs02mJe2DafgCgtSAy
2V4rRbF8mIsT96xSmj5WziQ=
=g3mt
-----END PGP SIGNATURE-----

David_Olofson · July 12, 2004, 2:01am

Using my own code, and another persons code, I’m getting 60 FPS
max for both programs when running in hardwaremode. Even though
mine draws and his doesn’t, and mines a higher resolution, I
still get the same FPS.

Does it max out on Win32 in hardwaremode in fullscreen mode? On
testing I actually got better FPS on software windowed mode than
Hardware mode. (70fps software windowed, 60fps hardware
fullscreen)

Or am I missing something really simple? From searching it looks
like it may be a cause of vsyncing,

Yep, that’s most probably it.

but it’s supposed to be a
good thing.

It is. An insane, unsynchronized frame rate is not. Vsync should be
used whenever possible, except when benchmarking.

Will an openGL backend to SDL give me better FPS?

No, not if your OpenGL driver has vsync enabled by default.

Do I need a
better FPS?

Well, yes (IMHO) and no. You cannot and should not exceed the refresh
rate of your monitor (it just burns CPU and GPU cycles and causes
tearing) - but I’d suggest configuring your monitor for a refresh
rate of at least 70 Hz, to reduce flickering. (If you can see any,
that is. Some people are more sensitive than others.)

Or should I just aim to hit over 30?

Depends on what kind of game you’re working on. Some games are
perfectly playable at 10-20 fps, whereas others need at least 30 fps
to be seriously playable at all. Increasing the frame rate to well
over 50 fps can often improve the feel and responsiveness. 2D action
games are usually the most sensitive ones (anyting below the monitor
refresh rate results in constant ghosting in scrollers, among other
things), though there is (to me at least) a distinct difference
between ~30 fps and 50+ fps in first person shooters as well.

For simulators and other applications that have to be very “direct” in
their responses to user input, you also have to consider latency,
especially if you’re using triple or better buffering. (Not supported
by SDL, unless the driver enforces it.) A higher frame rate reduces
latency without tearing or reduced “hickup resistance.”

//David Olofson - Programmer, Composer, Open Source Advocate

.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Sunday 11 July 2004 15.48, jake b wrote: