Performance on MacOS X in windowed mode

SDL Development
1

I was reading through some old mac-games-dev mailing list messages earlier today, and ran across some where the developers were saying that SDL performance on OS X in windowed mode was pretty terrible. (John Stiles, the author of Candy Crisis, had ported his game – which used to run well on a 100mhz PowerMac, to SDL – and it would then drop frames on a far faster computer… I think over 1 GHz if I remember correctly.)

I’ve just started experimenting with SDL, and it seems that little has changed. But specifically, I can take the “Aliens” demo (added the source code to the latest SDL 1.2.14 Cocoa project template), and if I remove the frame rate limit, it’ll drop significantly in speed the larger I make the window size. (Fullscreen this does not happen.)

Its behavior is consistent with a program that redraws the entire window every frame, rather than just updating delta rects. But this is not necessary, as dirty rects can/should be used.

Examples:
Fullscreen: 255 fps
Windowed 640x480: 60fps
Windowed 1024x768: 42 fps
Windowed 1280x800: 30fps

It appears that while fullscreen, SDL properly does dirty rects, and does not redraw the entire video memory buffer every frame. But in Windowed mode, it seems that it likely does.

First, is this fixed in SDL 1.3? Second, if not, are there any plans to address this?

2

Did a few more tests, and it seems for some reason two windowed sizes produce nearly identical results:

640x480 windowed: 60 fps
1024x640 windowed: 59fps
1280x800 windowed: 20fps

This leads me to believe if, in windowed mode, there is some sort of a frame rate “cap” at 60Hz. But this also does not explain 1280x800 being so very much slower. Also tried fullscreen, and yup, all tests are about the same speed, regardless of size:

640x480 fullscreen: 949 fps (it’s crazy fast)
1024x640 fullscreen: 1002 fps
1280x800 fullscreen: 966 fps

These are informal tests, done only once each run, so I’m guessing all the fullscreen results would vary within the ranges seen above. The point being, once you go fullscreen, window size doesn’t matter, as should be the case. But in windowed mode, window size slows things down the larger it gets, and is ridiculously slow for such a simple program. There surely must be a way to speed this up (without requiring hardware acceleration I would hope).

3

One more note: if I use

SDL_UpdateRect(screen, 0, 0, 0, 0);

instead of

SDL_UpdateRects(screen, numupdates, dstupdate);

all the framerates for windowed mode remain unchanged from what is posted above. (In theory, it should be much slower to use SDL_UpdateRect for hte entire window each frame.) Which, again, seems to confirm my suspicion that the entire window is being redrawn each frame, in additional to being capped to an imaginary VBL of some sort, when in Windowed mode on OS X.

Can anyone confirm this?

This is with SDL 1.2.14.

4

100mhz PowerMac

Could those even run OS X? But I know they don’t meet our 10.4 requirement now.

You’re talking about a system built over 10 years ago. I think its
safe to call those benchmarks completely irrelevant. Apple
re-optimizes or rewrites their implementations every major OS release.

To me, you are not benchmarking performance, you are effectively
benchmarking v-sync or the lack of it.

OS X likes to coalesce unnecessary drawing, particularly in windowed
mode to save system resources, so no matter how many times you try to
call draw, it’s going to cap. OS X uses a compositing window manager:

As for why 1280x800 windowed is slower for you, I don’t know. It may
have something to do with the hardware you are running. If you are
running a 100Mhz PowerMac, I might call those results pretty darn
good.

If you really want to understand the performance of your app on OS X,
you should use Shark and Instruments (DTrace).

-EricOn 12/10/09, VernJensen wrote:

I was reading through some old mac-games-dev mailing list messages earlier
today, and ran across some where the developers were saying that SDL
performance on OS X in windowed mode was pretty terrible. (John Stiles, the
author of Candy Crisis, had ported his game – which used to run well on a
100mhz PowerMac, to SDL – and it would then drop frames on a far faster
computer… I think over 1 GHz if I remember correctly.)

I’ve just started experimenting with SDL, and it seems that little has
changed. But specifically, I can take the “Aliens” demo (added the source
code to the latest SDL 1.2.14 Cocoa project template), and if I remove the
frame rate limit, it’ll drop significantly in speed the larger I make the
window size. (Fullscreen this does not happen.)

Its behavior is consistent with a program that redraws the entire window
every frame, rather than just updating delta rects. But this is not
necessary, as dirty rects can/should be used.

Examples:
Fullscreen: 255 fps
Windowed 640x480: 60fps
Windowed 1024x768: 42 fps
Windowed 1280x800: 30fps

It appears that while fullscreen, SDL properly does dirty rects, and does
not redraw the entire video memory buffer every frame. But in Windowed mode,
it seems that it likely does.

First, is this fixed in SDL 1.3? Second, if not, are there any plans to
address this?

5

hi,

Your tests seem to prove poorly performing dirty rect behaviour for
windowed mode. Can you make your changed versions available so other
people can reproduce the behaviour more easily?

cheers,On Fri, Dec 11, 2009 at 12:20 AM, VernJensen wrote:

Did a few more tests, and it seems for some reason two windowed sizes
produce nearly identical results:

640x480 windowed: 60 fps
1024x640 windowed: 59fps
1280x800 windowed: 20fps

This leads me to believe if, in windowed mode, there is some sort of a frame
rate “cap” at 60Hz. But this also does not explain 1280x800 being so very
much slower. Also tried fullscreen, and yup, all tests are about the same
speed, regardless of size:

640x480 fullscreen: 949 fps (it’s crazy fast)
1024x640 fullscreen: 1002 fps
1280x800 fullscreen: 966 fps

These are informal tests, done only once each run, so I’m guessing all the
fullscreen results would vary within the ranges seen above. The point being,
once you go fullscreen, window size doesn’t matter, as should be the case.
But in windowed mode, window size slows things down the larger it gets, and
is ridiculously slow for such a simple program. There surely must be a way
to speed this up (without requiring hardware acceleration I would hope).

6

[…]

100mhz PowerMac

Could those even run OS X? But I know they don’t meet our 10.4 requirement now.

You’re talking about a system built over 10 years ago. […]

If I understand the OP correctly, he isn’t :-)On Fri, 11 Dec 2009 03:29:17 -0800 “E. Wing” wrote:

7

I was reading through some old mac-games-dev mailing list messages earlier
today, and ran across some where the developers were saying that SDL
performance on OS X in windowed mode was pretty terrible. (John Stiles, the
author of Candy Crisis, had ported his game – which used to run well on a
100mhz PowerMac, to SDL – and it would then drop frames on a far faster
computer… I think over 1 GHz if I remember correctly.)

I’ve just started experimenting with SDL, and it seems that little has
changed. But specifically, I can take the “Aliens” demo (added the source
code to the latest SDL 1.2.14 Cocoa project template), and if I remove the
frame rate limit, it’ll drop significantly in speed the larger I make the
window size. (Fullscreen this does not happen.)

Its behavior is consistent with a program that redraws the entire window
every frame, rather than just updating delta rects. But this is not
necessary, as dirty rects can/should be used.

Examples:
Fullscreen: 255 fps
Windowed 640x480: 60fps
Windowed 1024x768: 42 fps
Windowed 1280x800: 30fps

It appears that while fullscreen, SDL properly does dirty rects, and does
not redraw the entire video memory buffer every frame. But in Windowed mode,
it seems that it likely does.

First, is this fixed in SDL 1.3? Second, if not, are there any plans to
address this?

I just looked at the source code in the aliens tar.gz file at
http://www.libsdl.org/projects/aliens/. The code, as posted on the web
site, uses dirty rectangles correctly and nothing inside of SDL 1.2
would allow the program to run without dirty rectangles working
correctly. That means this is not a problem with dirty rectangles, it
has to be somewhere else.

The original code calls for a software buffer. That means that SDL
should create the surface in system memory, use dirty rectangles to
update the buffer in memory, and then blit that whole buffer to the
display memory. That is what a software buffer does. So yes, it looks
like it is always doing a blit because it is. So, the “bug” is coded
into the original code. At the time the program was written, ten years
ago in December of 1999 the way it was written was not a bad way to
go. Times have changed?

The difference in speed between full screen and windowed updates seems
to be saying that OS X is only allowing blits to windows during
vertical refresh (the 60 hz frequency kind of gives it away) but is
allowing blits in full screen mode at any old time. I don’t know
because I haven’t spent the time to dig into the OS X rendering code.

SDL 1.3 works in a very different way. It will only use a shadow
buffer if it needs one to maintain compatibility with SDL 1.2 APIs
that are now only supported through emulation. Basically, the way
aliens was written back in December of 1999 was the best way to do it.
But that was 10 years ago. It is no longer a reasonable way to write a
game and SDL 1.3 is being implemented to use techniques that are
likely to be valid for at least the next 10 years.

Seriously, 10 years? That is 5 cranks of Moore’s Law. That represents
a 2**5 or 32 times increase in computer performance.

Bob PendletonOn Thu, Dec 10, 2009 at 6:03 PM, VernJensen wrote:

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

–
±----------------------------------------------------------