Just to give another data point, we ran into this issue as well a few days ago. We were unable to link our app under Xcode 4 without removing the CGLSetFullScreen() call. Building the app with Xcode 3.2, even on a Lion system, was okay and the resulting binary ran fine on Lion systems. In our case, the original and tweaked SDL libraries were built with Xcode 3.
In testing our app (Aleph One), we found that the Lion-compatible fullscreen method was much slower on older systems than the CGBaseDisplayAddress() method. So, we put together a version of SDL_QuartzVideo.m that only switches to the new code path on Lion systems. This may be helpful for others who experience the same performance problems we did. Patch is attached against 5574, or you can grab the entire file at:
Jeremiah sent this patch for improved Lion support to the list back in
August, and it still hasn’t been approved. Let’s see if I can get it
through.
GregoryBegin forwarded message:
From: Jeremiah Morris
Subject: Re: Mac OS X Lion testing…
Date: 11 August 2011 12:47:33 AM EDT
To: sdl at lists.libsdl.org
Just to give another data point, we ran into this issue as well a few
days ago. We were unable to link our app under Xcode 4 without removing
the CGLSetFullScreen() call. Building the app with Xcode 3.2, even on a
Lion system, was okay and the resulting binary ran fine on Lion systems.
In our case, the original and tweaked SDL libraries were built with
Xcode 3.
In testing our app (Aleph One), we found that the Lion-compatible
fullscreen method was much slower on older systems than the
CGBaseDisplayAddress() method. So, we put together a version of
SDL_QuartzVideo.m that only switches to the new code path on Lion
systems. This may be helpful for others who experience the same
performance problems we did. Patch is attached against 5574, or you can
grab the entire file at:
Jeremiah sent this patch for improved Lion support to the list back in
August, and it still hasn’t been approved. Let’s see if I can get it
through.
I just merged this with the rest of the Lionizing work (is that even a
word? It is now!), and put it in revision control. It’s hg changeset
6b62ce1bff72.
I completely forgot to credit Jeremiah in the commit message (for which
I apologize).
I’ve only tested this on Lion. I imagine we’ll need another patch or two
to get this solid everywhere, as the 1.2 Quartz target has become a
rather nasty pile of #ifdefs and APIs in various states of deprecation.
Buildbot isn’t too upset with it, but I’ll test it on other machines soon.
I would encourage others to test it, too. If you’ve had problems, this
might solve them. If you didn’t: maybe now you do. Please test and
report back!
(my quick-and-dirty testing methodology looks like this:
I’ll test it tonight on my Lion laptop with the pygame unit tests.
cheers!On Wed, Sep 14, 2011 at 2:52 AM, Ryan C. Gordon wrote:
Jeremiah sent this patch for improved Lion support to the list back in
August, and it still hasn’t been approved. Let’s see if I can get it
through.
I just merged this with the rest of the Lionizing work (is that even a
word? It is now!), and put it in revision control. It’s hg changeset
6b62ce1bff72.
I completely forgot to credit Jeremiah in the commit message (for which I
apologize).
I’ve only tested this on Lion. I imagine we’ll need another patch or two to
get this solid everywhere, as the 1.2 Quartz target has become a rather
nasty pile of #ifdefs and APIs in various states of deprecation. Buildbot
isn’t too upset with it, but I’ll test it on other machines soon.
I would encourage others to test it, too. If you’ve had problems, this
might solve them. If you didn’t: maybe now you do. Please test and report
back!
(my quick-and-dirty testing methodology looks like this:
hmm, ran into some problems. First of all Exult still has problems with the white screen on switching to fullscreen and back as reported in the other thread. Curiosly dosbox doesn’t have that problem anymore but then I’m compiling and running Dosbox in 32bit mode if that changes anything.
Except for the white screen issue, Exult runs fine in 64bit on Lion. My 32bit compile crashes on Lion. Same with my Pentagram 32bit build
Curiosly, Dosbox, Exult and Pentagram display (on the terminal) “CGDisplayBaseAddress is obsolete and returning NULL for display 0x42801c0” when switching to fullscreen. So it seems the 32bit build is again having THAT problem. Why it doesn’t crash Dosbox now is beyond me.
Further information:
SDL, Dosbox, Exult and Pentagram have been built with gcc 4.0 against the 10.4 SDK (since building it for 10.6 or 10.7 SDK doesn’t produce 32bit binaries that run on 10.5 for some reason).
“CGDisplayBaseAddress is obsolete and returning NULL for display
0x42801c0” when switching to fullscreen.
SDL, Dosbox, Exult and Pentagram have been built with gcc 4.0 against
the 10.4 SDK (since building it for 10.6 or 10.7 SDK doesn’t produce
32bit binaries that run on 10.5 for some reason).
I just put some fixes in revision control that might resolve this; let
me know if it’s better for you.
I think the reason you don’t see it is because it only happens on changing surface fullscreen/windowed mode. AFAIKT the SDL test programs that could showcase it only have the option to start in either mode but not change the mode while running. When I start Exult, Pentagram, Dosbox in fullscreen or windowed mode I don’t get the whiteness, only when I change the mode while running do I see this.
(note my above puzzlement that Dosbox didn’t crash on fullscreen nor showed the whiteness was because Dosbox was using OpenGL output mode - in surface it behaves as expected, crash in 32bit and whiteness in 64bit mode)
I think the reason you don’t see it is because it only happens on changing surface fullscreen/windowed mode. AFAIKT the SDL test
programs that could showcase it only have the option to start in either
mode but not change the mode while running. When I start Exult,
Pentagram, Dosbox in fullscreen or windowed mode I don’t get the
whiteness, only when I change the mode while running do I see this.
ok, tested the new code. Unfortunately this time with this SDL Exult only ran in 32bit mode on the SDK system it was built in 32bit mode for (I’m running Leopard and SL in a VM). Otherwise the console message is Unable to initialize SDL: Couldn’t figure out current display mode.
When I built Exult against 10.5 SDK it ran in Leopard (but refused to run on Lion and SL).
Something strange.
Another thing I noticed before with the other build, Exult would behave very very slow in fullscreen in the VMs. I only noticed that because it ran quite fine with earlier SDL code in fullscreen (I keep snapshots so I tested it right now).
the culprit is the if FORCE_OLD_API stuff. When I add this back the 32bit builds start again, but will crash on Lion as they are using the deprecated stuff
Btw, I just tried the patch by Gregory/Jeremy and with that I don’t have these problems (except the whiteness bug). 32 bit build seems to work fine and doesn’t crash on switching to fullscreen. Gonna try how the ppc and 64bit build will behave now.
The patch needed some manual work, especially line 150 (goto ERR_DOUBLEBUF;) needed commenting out because it wouldn’t compile as it wasn’t defined before. So whatever that does, it won’t do anything right now
I think the reason you don’t see it is because it only happens on changing surface fullscreen/windowed mode. AFAIKT the SDL test
programs that could showcase it only have the option to start in either
mode but not change the mode while running. When I start Exult,
Pentagram, Dosbox in fullscreen or windowed mode I don’t get the
whiteness, only when I change the mode while running do I see this.
Okay, I’ll look into that, too.
The white screen is now fixed, in hg changeset 6e618c16a861.
I removed the FORCE_OLD_API stuff in revision control last night (hg
changeset fc557e459527); are you still having problems?
–ryan.On 9/15/11 3:48 PM, Dominus wrote:
the culprit is the if FORCE_OLD_API stuff. When I add this back the
32bit builds start again, but will crash on Lion as they are using the
deprecated stuff Sad
Yes, my post from the 14th was referring to that. Without the force old
api stuff, all the 32bit builds won’t start on Lion, failing to init SDL.
Ok, this should all be fixed in revision control now.
Here’s what I did:
Built SDL, testalpha, and testgl as x86 with the 10.4u SDK.
Ran it on 10.4, 10.5, 10.6, and 10.7.
Ran ./testalpha, and then hit “t” to toggle fullscreen/windowed, back
and forth, to make sure both transitions worked.
Same test again, but with ./testalpha -fullscreen
Run ./testgl, make sure it works.
Same thing, but with ./testgl -fullscreen.
Same thing, but with ./testgl -sync
Same thing, but with ./testgl -fullscreen -sync
All of the above, but built with x86+10.7 SDK and run on Lion.
All of the above, but built with x86_64+10.7 SDK and run on Lion.
…and this is all working!
I have not tested any PowerPC builds (so no 10.3 or lower, either). I
don’t really care at all about these. If someone cares and there’s a
problem, please report it.
I also didn’t run testgl with toggling windowed/fullscreen. You can see
what I did in testalpha and replicate it if you have a problem there and
need a test case:
I’ll be able to test this evening or maybe tomorrow (CET). But thanks for the hard work on this. I hope everything works fine and I don’t need to bug you again
Ok, this should all be fixed in revision control now.
Here’s what I did:
Built SDL, testalpha, and testgl as x86 with the 10.4u SDK.
Ran it on 10.4, 10.5, 10.6, and 10.7.
Ran ./testalpha, and then hit “t” to toggle fullscreen/windowed, back and
forth, to make sure both transitions worked.
Same test again, but with ./testalpha -fullscreen
Run ./testgl, make sure it works.
Same thing, but with ./testgl -fullscreen.
Same thing, but with ./testgl -sync
Same thing, but with ./testgl -fullscreen -sync
All of the above, but built with x86+10.7 SDK and run on Lion.
All of the above, but built with x86_64+10.7 SDK and run on Lion.
…and this is all working!
I have not tested any PowerPC builds (so no 10.3 or lower, either). I don’t
really care at all about these. If someone cares and there’s a problem,
please report it.
I also didn’t run testgl with toggling windowed/fullscreen. You can see what
I did in testalpha and replicate it if you have a problem there and need a
test case:
I think the only problem that might still be pending is Exult having a
strange offset for video rendering. Let me know if that’s still busted, too.
Ryan,
That’s great to hear. We’ve got too much going on to test this right
now–we’re going with the patch I forwarded for our upcoming release. But
right after that I will try this out. We still have some PowerPC users to
support, so I’ll let you know how that goes too.
Thanks for spending time on what must seem old and broken after working on
1.3
Further report:
If I compile both SDL and Exult against SDK 10.6 x86_64 built works fine in fullscreen on both Lion and SL. A built against SDK 10.7 (both SDL and Exult) used to work on SL as I wrote earlier.
With SDL’s testalpha I made the same test. SDL and test alpha compiled against SDK 10.7 makes test alpha -fullscreen crash on SL with a segfault.
I can live with building against SDK 10.6 to make a compatible snapshot, I still wonder though, as it used to work whether it can be made to work again.
- in surface it behaves as expected, crash in 32bit and whiteness in 64bit mode)