Huge decrease in performance in SDL 1.2.15 on older Macs

I am a developer on a project called Odamex. One of my specific tasks is to maintain Odamex on Mac and produce the Mac releases. I started doing this around the time the switch from PowerPC to Intel occurred and so for a short period of time I did build on a G4 ppc before switching. Performance was pretty good especially in fullscreen. Since then we have continued to provide universal builds that are compatible with 10.4 Tiger and up. Of course we were affected by the fullscreen bug that was introduced with 10.7 Lion. When the fixed version of SDL was released we upgrade and that was what we used in our next release. Recently I acquired a 1.67GHz PowerBook G4. I installed Odamex straight from our site and I was surprised to find the performance was awful. In fullscreen the game is a slideshow. I downloaded the version previous to the latest and I found it performed the way I remembered. There wasn’t much of a difference in windowed mode but fullscreen was night and day faster
. I immediately attributed the issue to the fullscreen fix and set out to find an answer to the problem. I found out that Wesnoth is using a custom framework that uses the new code path on Lion and the old code path on older version of OS X. I pulled the framework out of Wesnoth and dropped it into Odamex. It did fix the performance issues. Unfortunately it crashes sometimes when changing resolutions. I then decided to pull the SDL 1.2 branch from Mercurial and build it myself to see if further fixes have been applied. It performs the same as SDL 1.2.15.

So now I am trying to decide how best to proceed. We could begin releasing two Mac packages where one contains SDL 1.2.14 and the other contains SDL 1.2.15 but that does not seem like the best solution. We could also consider dropping ppc support and bumping the min version on our build but I am strongly opposed to dropping that support. Our portability is very important to us. That is why we chose SDL in the first place. Another option is for me to come in here and ask how I can help get this issue resolved in SDL. I am willing to test out of the repository as well as patches on ppc hardware. Thanks.

I’ve tried hard over the years to keep supported PPC, and I think I have supported it longer than I probably should have. I think it is worth it to analyze how many people are still using PPC and consider it if is worth it to keep supporting it. I’m not sure you can even make PPC programs with the latest Xcode (at least without jumping through hoops).

Well I know of at least two active members of our user community who primarily use Odamex on ppc. Considering the fact that most users who download the software do so without becoming active in the community I believe there has to be more who do so if the active community is representative of our user base as a whole. Even if it was just those two active members that would be enough to convince me to continue supporting it. So let’s assume that ppc support is a critical requirement of our software and that dropping support for it is the last option we would consider.

Another thing that I would like to note is that this is not primarily a PowerPC issue. It is a performance issue. Overall SDL is working fine on ppc. The code introduced to fix fullscreen in Lion seems to be much slower than the old code. I can only provide the results I have experienced with the machines that I have. I am willing to bet that this code is not much faster on an early single-core Intel Mac. So eliminating support for machines that have had fullscreen crippled by the Lion fix would probably require more than just eliminating PowerPC support.

What exactly do you mean by slower? You talking about maximum fps? I suggest you try disabling various things in a controlled way and see what affects the speed. For example, try disabling images, then try disabling text, and so on, until you notice a speed improvement.

Have you tried SDL2? That’s what I use now.

What I mean by slow is that with SDL versions previous to 1.2.15 Odamex is perfectly playable on the machine in question in fullscreen mode. When I switch to 1.2.15 it becomes a slideshow. I know that it is the difference between the new fullscreen code and the old because the framework pulled from Wesnoth simply uses the old code for any version of OS X previous to Lion and the new code for Lion+. It works very well on both the machine that I’m having an issue with as well as a newer machine running Lion. The only problem is that it can crash when changing resolutions on both machines though I think it is unrelated to the fullscreen code. I think the crash in that framework is actually related to a windowed mode “fix” that was put in to make windowed mode faster which is typically much slower than fullscreen mode when using SDL on OS X. The code that was put in for that appears to use deprecated API which I see warnings about on the shell only when using that framework.

In order to show how much of a difference there is between SDL 1.2.14 and SDL 1.2.15 on Mac I used the Apple Developer profiler tool called Shark. I ran it with Odamex built against both versions of SDL and here are the results.

With SDL 1.2.14, which runs quite smoothly, this is the top of the Shark output (anything 1.0%+):

Report 1 - Odamex SDL 14 - Time Profile.mshark - Time Profile of odamex

SharkProfileViewer

Generated from the visible portion of the outline view

  • 18.2%, R_DrawColumnHorizP_C(), odamex
  • 17.2%, I_Blit(DCanvas*, int, int, int, int, DCanvas*, int, int, int, int), odamex
  • 15.2%, rt_map4cols_c(int, int, int), odamex
  • 14.1%, __memcpy, libobjc.A.dylib
  • 11.5%, R_DrawSpanP_C(), odamex
  • 2.4%, wipe_doMelt(int), odamex
  • 1.5%, BestColor(unsigned int const*, int, int, int, int), odamex
  • 1.2%, rt_copy4cols_c(int, int, int), odamex
  • 1.2%, DCanvas::DrawLucentPatchSP(unsigned char const*, unsigned char*, int, int, int), odamex
  • 1.0%, BlastColumn(void (*)()), odamex

With SDL 1.2.15, which runs like a slideshow, here is the top of the Shark output (anything 1.0%+):

Report 0 - Odamex SDL 15 - Time Profile.mshark - Time Profile of odamex

SharkProfileViewer

Generated from the visible portion of the outline view

  • 63.7%, SDL_AddTimer, SDL
  • 6.1%, R_DrawColumnHorizP_C(), odamex
  • 5.3%, rt_map4cols_c(int, int, int), odamex
  • 4.2%, I_Blit(DCanvas*, int, int, int, int, DCanvas*, int, int, int, int), odamex
  • 4.0%, R_DrawSpanP_C(), odamex
  • 2.3%, wipe_doMelt(int), odamex
  • 1.5%, BestColor(unsigned int const*, int, int, int, int), odamex

You can see the complete logs here:
http://www.huntsvegas.org/development/odamex/Odamex%20SDL%2014%20-%20Time%20Profile.txt
http://www.huntsvegas.org/development/odamex/Odamex%20SDL%2015%20-%20Time%20Profile.txt

This is a pretty big difference. It is obvious that the slowdown is definitely in SDL. Also, as far as I can tell this slowdown doesn’t only affect older hardware or 10.4 - 10.5. I see a noticeable difference in framerate on my Lion machine as well. Odamex has a max framerate of 35fps (inherited from Doom) but with the latest SDL I am seeing sub-30 with an Intel Core 2 Duo 2.26GHz, 8GB 1066MHz DDR3 memory, and Nvidia GeForce 9400 256 MB graphics adapter. There is no reason why this hardware shouldn’t peg the max fps when running Odamex. I would like to collect the same information on this machine but Apple did away with Shark and replaced it with Instruments which is integrated into Xcode as far as I can tell. I will try to run that tool as soon as possible.

Hello !

  • 63.7%, SDL_AddTimer, SDL

I do not know the SDL internals very well, but it seems strange
that it is spending most of its time in SDL_AddTimer and not some
drawing function or something like that.

Other emails in the archive said that changes in the OSX screen backend
would cause slowdowns on older OSX versions, but nothing about SDL_Timer stuff.

Is there any way to debug it further ?

CU

The last post I made where I had used a debug build of SDL it shows Blit1to4() (called from SDL_SoftBlit()) as being the method eating up all the time. In both cases SDL_Flip() was on the stack. Because the first profile was created with a release build and the last one with a debug build I think I would put a lot more stock in the last one.

It seems that post never made it to the list. The forums were acting awfully funny at the time. Here is the post I am referring to: http://forums.libsdl.org/viewtopic.php?p=33257#33257

Can you do the same profile with SDL 1.2.14? Maybe palette hardware is no
longer supported in 1.2.15?On Mon, Jun 25, 2012 at 5:15 PM, Hyper_Eye wrote:

**
The last post I made where I had used a debug build of SDL it shows
Blit1to4() (called from SDL_SoftBlit()) as being the method eating up all
the time. In both cases SDL_Flip() was on the stack. Because the first
profile was created with a release build and the last one with a debug
build I think I would put a lot more stock in the last one.


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

If you built SDL with the newest tools and didn’t set
-mmacosx-version-min=10.4, it’s likely that we think you want an SDL
that’s only meant to run on 10.7 or later, and so we removed all the
legacy code from your build (as it will trigger deprecation warnings on
the newer toolchain, and possibly get you rejected from the Mac App Store).

A lot of effort was made to allow the deprecated code to be in there and
do the right thing on older systems (while using the newer code on newer
systems, too!), though, if you tell the system to build with an older
SDK, so this might be a solvable problem for you.

I’ve sort of come to the conclusion that the only way to ever win this
game is to use OpenGL, though.

–ryan.On 6/25/12 8:15 PM, Hyper_Eye wrote:

The last post I made where I had used a debug build of SDL it shows
Blit1to4() (called from SDL_SoftBlit()) as being the method eating up
all the time. In both cases SDL_Flip() was on the stack. Because the
first profile was created with a release build and the last one with a
debug build I think I would put a lot more stock in the last one.

I built it with Xcode3 on OS X 10.5 Leopard using a powerbook. I built against the 10.4 SDK and set the target to 10.4. I set it to build a 32-bit universal (ppc, i386) framework. Sorry I haven’t gotten the 1.2.14 profiler results done yet. I’ve been short on time the last week. Thanks for looking at this issue.