SDL on Mac OS X Tiger 10.4

J_Ryan_Sobol · May 9, 2005, 12:07am

Has anyone experienced odd behavior with SDL 1.2.7 on Tiger? I’ve seen
a few threads on the Internet claiming a handful of SDL-based, Mac
ported games are broken.

http://www.idevgames.com/forum/showthread.php?postid=86369
http://episteme.arstechnica.com/eve/ubb.x/a/tpc/f/8300945231/m/632008292731/p/6

~ ryan ~

Bob_Ippolito · May 9, 2005, 1:18am

Has anyone experienced odd behavior with SDL 1.2.7 on Tiger? I’ve
seen a few threads on the Internet claiming a handful of SDL-based,
Mac ported games are broken.

http://www.idevgames.com/forum/showthread.php?postid=86369
http://episteme.arstechnica.com/eve/ubb.x/a/tpc/f/8300945231/m/
632008292731/p/6

Looking at those URLs, I see one probably broken game, and some claim
that the full screen code for SDL might be broken in tiger but no
specific evidence that it is? I haven’t noticed any issues myself,
but I haven’t used SDL much since I installed Tiger. My first guess
would be that the broken game is simply using threads and/or events
incorrectly, and changes in Tiger made that more obvious…

-bobOn May 8, 2005, at 8:07 PM, J. Ryan Sobol wrote:

icculus · May 9, 2005, 1:45am

Has anyone experienced odd behavior with SDL 1.2.7 on Tiger? I’ve
seen a few threads on the Internet claiming a handful of SDL-based,
Mac ported games are broken.

“And yes, kittens and loop both need a lot of the interface niceties to
be implemented, niceties which are supposedly fixed in newer versions of
SDL; unfortunately, my Mac is so messed up that SDL refuses to install”

…Yeah, that totally sounds like SDL’s fault.

fwiw, I’ve got both 2D and 3D stuff using SDL that continues to work in
Tiger.

Note that a fresh install of Tiger defaults to gcc 4.0.0, though, so it
might have issues. First thing I did was run gcc_select to put it back
to 3.3.

The windowed 2D performance seems to have dropped somewhat on my
Powerbook in Tiger whereas GL apps seem mostly the same, but I haven’t
done a formal benchmark, and could have imagined the whole thing.

–ryan.

Arne_Claus · May 12, 2005, 9:50am

Note that a fresh install of Tiger defaults to gcc 4.0.0, though, so
it might have issues. First thing I did was run gcc_select to put it
back to 3.3.

I tried to run the sdl-devel package (1.2.8) on a fresh tiger
installation, but it does not install the framework - neither in
~/Library/Frameworks nor in /Library/Frameworks. The last time I did
that on Panther it worked … the funny thing is, that the docs are
correctly installed.
The SDL_net package installer (older version) refuses to install
completely. Btw - is there any installer with the current versions of
sdl_net and sdl_image? Afair there were installers around but they have
somehow disappeared from the library pages.

The windowed 2D performance seems to have dropped somewhat on my
Powerbook in Tiger whereas GL apps seem mostly the same, but I haven’t
done a formal benchmark, and could have imagined the whole thing.

Hmm … I already wanted to ask how the quartz-changes affect sdl.
According to an Ars-Technica article Apple moved the rendering (of e.g.
Fonts) on the gpu, too - if I understood that correctly. I thought that

due to that - sdl should be faster now …
Has anybody done some blits per second tests with tiger yet? I did that
on Jaguar once and the results were quite poor compared to
windows-machines.

BR Arne

Arne_Claus · May 12, 2005, 10:43am

There was a question if SDL is faster or slower on OSX 10.4.

Well - I did a little benchmark based on the tutorial code that comes
with the osx-package (code pasted below).
The programm loads a bmp (128x128, blits it onto the screen (no flip),
counts the blits and displays an average on the console afterwards.
If you’ve got any suggestions how to make this thing faster - please
post them. I only remebered converting the image to the display-format.

Results (SDL 1.2.8):
G5 Dual 2.0, Radeon 9800, OSX 10.3.9:
about 20k blits/s

G4 1.5 (Powerbook), Radeon 9700, OSX 10.4.0:
about 6.5k blits/s

Still pretty slow IMHO. If I remeber correctly, windows came around
with some 100k - would be nice if someone could confirm this, as I
haven’t got any windows- pc around here.

BR Arne

Here’s the code

— 8< —

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <math.h>
#include <SDL.h>

int main(int argc, char *argv[])
{
int done;
int blits;
int start_time;
int end_time;
int time;
SDL_Event event;
SDL_Surface *screen;
SDL_Surface *sprite;

if (SDL_Init(SDL_INIT_VIDEO | SDL_INIT_TIMER | SDL_ANYFORMAT) < 0) {
	fprintf(stderr, "Couldn't initialize SDL: %s\n", SDL_GetError());
	exit(1);
}

if ((screen=SDL_SetVideoMode(800,600, 32, SDL_SWSURFACE |

SDL_ANYFORMAT)) == NULL) {
fprintf(stderr, “Couldn’t set 800x600x32 video mode: %s\n”,
SDL_GetError());
SDL_Quit();
exit(2);
}

sprite = SDL_DisplayFormat(SDL_LoadBMP("test.bmp"));

done=0;
blits=0;
start_time = SDL_GetTicks();

while (!done) {
	SDL_BlitSurface(sprite, NULL, screen, NULL);
	blits++;
	
	while (SDL_PollEvent(&event))
		if (event.type==SDL_KEYDOWN)
			done=1;
}

end_time = SDL_GetTicks();
time = end_time - start_time;
printf("SDL did %d blits in %d ms, that's about %0.2f

blits/second.\n", blits, time, blits/(time/1000.0f));

SDL_FreeSurface(sprite);
SDL_Quit();
return(0);

}

— >8 —

Jeremy_Johnstone · May 12, 2005, 3:04pm

How does this compare Tiger vs Panther?
One is Tiger and the other is Panther, BUT complete different hardware.

What speed did you get on the Powerbook with Panther?

— Arne Claus wrote:

There was a question if SDL is faster or slower on OSX 10.4.

Well - I did a little benchmark based on the tutorial code that comes
with the osx-package (code pasted below).
The programm loads a bmp (128x128, blits it onto the screen (no flip),
counts the blits and displays an average on the console afterwards.
If you’ve got any suggestions how to make this thing faster - please
post them. I only remebered converting the image to the display-format.

Results (SDL 1.2.8):
G5 Dual 2.0, Radeon 9800, OSX 10.3.9:
about 20k blits/s

G4 1.5 (Powerbook), Radeon 9700, OSX 10.4.0:
about 6.5k blits/s

Still pretty slow IMHO. If I remeber correctly, windows came around
with some 100k - would be nice if someone could confirm this, as I
haven’t got any windows- pc around here.

BR Arne

Here’s the code

— 8< —

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <math.h>
#include <SDL.h>

int main(int argc, char *argv[])
{
int done;
int blits;
int start_time;
int end_time;
int time;
SDL_Event event;
SDL_Surface *screen;
SDL_Surface *sprite;

if (SDL_Init(SDL_INIT_VIDEO | SDL_INIT_TIMER | SDL_ANYFORMAT) < 0) {
fprintf(stderr, “Couldn’t initialize SDL: %s\n”, SDL_GetError());
exit(1);
}

if ((screen=SDL_SetVideoMode(800,600, 32, SDL_SWSURFACE |
SDL_ANYFORMAT)) == NULL) {
fprintf(stderr, “Couldn’t set 800x600x32 video mode: %s\n”,
SDL_GetError());
SDL_Quit();
exit(2);
}

sprite = SDL_DisplayFormat(SDL_LoadBMP(“test.bmp”));

done=0;
blits=0;
start_time = SDL_GetTicks();

while (!done) {
SDL_BlitSurface(sprite, NULL, screen, NULL);
blits++;
  while (SDL_PollEvent(&event))
  	if (event.type==SDL_KEYDOWN)
  		done=1;
}

end_time = SDL_GetTicks();
time = end_time - start_time;
printf(“SDL did %d blits in %d ms, that’s about %0.2f
blits/second.\n”, blits, time, blits/(time/1000.0f));

SDL_FreeSurface(sprite);
SDL_Quit();
return(0);
}

— >8 —

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

http://jeremy.doverstreet.dhs.org
http://www.humpthechef.com
http://www.all-psp.com

Gabriele_Greco · May 12, 2005, 4:05pm

Arne Claus wrote:

Still pretty slow IMHO. If I remeber correctly, windows came around with
some 100k - would be nice if someone could confirm this, as I haven’t
got any windows- pc around here.

I wonder if this test is meaningful since the bitmap is too small and
fits for sure in the L2 cache of x86 processors (don’t know about the
size of g4/5).

Anyway this is the result on an x86 linux box (athlon XP2100+, GF4mx 220):

SDL did 187681 blits in 8018 ms, that’s about 23407.46 blits/second.

Bye,
Gabry

Richard_Schreyer · May 12, 2005, 4:25pm

Tiger did introduce the ability to do all 2D rendering on the GPU,
including font rendering, with 2 important points to consider:

This ability is disabled by default in 10.4.0, for unknown reasons,
it is probably not quite ready to go yet. Enable it in Quartz Debug.
It will not benifit SDL (2D), as SDL does all it’s blitting in it’s
own code, instead of using CoreGraphics primitives (which show
impressive speedups).

Secondly, while your blit test is interesting, there is already a
blittest program in the tests folder that is fairly complete. The exact
results of your test also depend on you providing us the BMP you used,
as the exact image could have a significant performance impact. ie, the
specific color depth in your BMP may or may not allow one of the Altivec
enhanced blitters to work.

I don’t know if the Altivec blitters made it into 1.2.8, or they are
waiting on 1.2.9. This will make a huge difference in 2D performance.

Richard

Arne Claus wrote:> There was a question if SDL is faster or slower on OSX 10.4.

Well - I did a little benchmark based on the tutorial code that comes
with the osx-package (code pasted below).
The programm loads a bmp (128x128, blits it onto the screen (no flip),
counts the blits and displays an average on the console afterwards.
If you’ve got any suggestions how to make this thing faster - please
post them. I only remebered converting the image to the display-format.

Results (SDL 1.2.8):
G5 Dual 2.0, Radeon 9800, OSX 10.3.9:
about 20k blits/s

G4 1.5 (Powerbook), Radeon 9700, OSX 10.4.0:
about 6.5k blits/s

Still pretty slow IMHO. If I remeber correctly, windows came around with
some 100k - would be nice if someone could confirm this, as I haven’t
got any windows- pc around here.

BR Arne

Here’s the code

— 8< —

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <math.h>
#include <SDL.h>

int main(int argc, char *argv[])
{
int done;
int blits;
int start_time;
int end_time;
int time;
SDL_Event event;
SDL_Surface *screen;
SDL_Surface *sprite;
if (SDL_Init(SDL_INIT_VIDEO | SDL_INIT_TIMER | SDL_ANYFORMAT) < 0) {
    fprintf(stderr, "Couldn't initialize SDL: %s\n", SDL_GetError());
    exit(1);
}

if ((screen=SDL_SetVideoMode(800,600, 32, SDL_SWSURFACE |
SDL_ANYFORMAT)) == NULL) {
fprintf(stderr, “Couldn’t set 800x600x32 video mode: %s\n”,
SDL_GetError());
SDL_Quit();
exit(2);
}
sprite = SDL_DisplayFormat(SDL_LoadBMP("test.bmp"));

done=0;
blits=0;
start_time = SDL_GetTicks();

while (!done) {
    SDL_BlitSurface(sprite, NULL, screen, NULL);
    blits++;
   
    while (SDL_PollEvent(&event))
        if (event.type==SDL_KEYDOWN)
            done=1;
}

end_time = SDL_GetTicks();
time = end_time - start_time;
printf("SDL did %d blits in %d ms, that's about %0.2f
blits/second.\n", blits, time, blits/(time/1000.0f));
SDL_FreeSurface(sprite);
SDL_Quit();
return(0);
}

— >8 —

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

Arne_Claus · May 12, 2005, 5:57pm

This ability is disabled by default in 10.4.0, for unknown reasons,
it is probably not quite ready to go yet. Enable it in Quartz Debug.

Now that’s interesting - didn’t know that

It will not benifit SDL (2D), as SDL does all it’s blitting in it’s
own code, instead of using CoreGraphics primitives (which show
impressive speedups).

Hmm … guessed that - but now I know for sure =)

Secondly, while your blit test is interesting, there is already a
blittest program in the tests folder that is fairly complete.

Oh - didn’t know that. Where can I find that folder - cvs?

The exact
results of your test also depend on you providing us the BMP you used,
as the exact image could have a significant performance impact.
ie, the
specific color depth in your BMP may or may not allow one of the
Altivec
enhanced blitters to work.

I used a 32bpp bitmap but as the code converts it into the screen
surface (32bpp, too) there should be no difference - if you use a
128x128 image and I understood the conversion process correctly. I
guess the only variant where Altivec would fail would be 16bpp.

I don’t know if the Altivec blitters made it into 1.2.8, or they are
waiting on 1.2.9. This will make a huge difference in 2D performance.

AFAIR the altivec blits did not made it into 1.2.8, but I don’t read
this list that regularly.

BR Arne

Eric_Wing · May 12, 2005, 8:29pm

Note that a fresh install of Tiger defaults to gcc 4.0.0, though, so
it might have issues. First thing I did was run gcc_select to put it
back to 3.3.

I tried to run the sdl-devel package (1.2.8) on a fresh tiger
installation, but it does not install the framework - neither in
~/Library/Frameworks nor in /Library/Frameworks. The last time I did
that on Panther it worked … the funny thing is, that the docs are
correctly installed.
The SDL_net package installer (older version) refuses to install
completely. Btw - is there any installer with the current versions of
sdl_net and sdl_image? Afair there were installers around but they have
somehow disappeared from the library pages.

The breakup between the sdl-devel and sdl packages has changed. This
is intentional. The sdl package now contains a “proper” framework, now
conforming to Apple conventions. This means both the runtime library
and headers are contained in the Framework (as they are supposed to
be). The sdl-dev package contains the documentation and Xcode
templates.

The old behavior of creating a framework, splitting it up into two
separate frameworks, and then putting them into separtate places was
horribly broken and had to die for a significant list of reasons. (If
you have ever done a multiuser setup or zerolink, you might understand
why. The complicated process in doing this operation was probably the
ultimate reason your old sdl_net package refuses to install.) The sdl
frameworks are actually drag-n-dropable, so I’ve been wondering if
making a .dmg instead of a package would be better. (The dev-package
is fancy so it will still need a .pkg.)

As for the SDL satellite packages, check the archives. I just posted
on this yesterday. They too are following the proper framework
convention. There is no longer a need for separate dev versions of
those packages.

-Eric> From: Arne Claus

Subject: Re: [SDL] SDL on Mac OS X Tiger 10.4

Bob_Ippolito · May 13, 2005, 12:29am

Tiger did introduce the ability to do all 2D rendering on the GPU,
including font rendering, with 2 important points to consider:

This ability is disabled by default in 10.4.0, for unknown reasons,
it is probably not quite ready to go yet. Enable it in Quartz Debug.

It will not benifit SDL (2D), as SDL does all it’s blitting in it’s
own code, instead of using CoreGraphics primitives (which show
impressive speedups).

Secondly, while your blit test is interesting, there is already a
blittest program in the tests folder that is fairly complete. The
exact
results of your test also depend on you providing us the BMP you used,
as the exact image could have a significant performance impact.
ie, the
specific color depth in your BMP may or may not allow one of the
Altivec
enhanced blitters to work.

I don’t know if the Altivec blitters made it into 1.2.8, or they are
waiting on 1.2.9. This will make a huge difference in 2D performance.

The pygame packages at http://pythonmac.org/packages/ will install
SDL frameworks that are AltiVec optimized. They’re somewhere between
1.2.8 and CVS, before my AltiVec blitters were merged to trunk and I
was maintaining them on a fork in my svn repo. I’m sure I mentioned
this on the archives somewhere, and probably also at http://
bob.pythonmac.org/ two or three times.

-bobOn May 12, 2005, at 12:25 PM, Richard Schreyer wrote:

icculus · May 13, 2005, 7:30pm

Hmm … I already wanted to ask how the quartz-changes affect sdl.
According to an Ars-Technica article Apple moved the rendering (of e.g.
Fonts) on the gpu, too - if I understood that correctly. I thought that

due to that - sdl should be faster now …

Probably irrelevant to how 2D graphics get from main memory to video RAM
every frame.

In many ways, it’s getting to the point where you need to use OpenGL to
get good performance on even 2D games…doubly so on the Mac, where you
can guarantee more than enough 3D power to make a couple hundred
textured quads render with no concern for framerate.

Has anybody done some blits per second tests with tiger yet? I did that
on Jaguar once and the results were quite poor compared to
windows-machines.

Up until recently, OSX blitting was on the slowpath through SDL. Bob
Ippolito spent some time replacing all that with Altivec code, which is
now in CVS but hasn’t yet made it into a formal SDL release.

–ryan.

icculus · May 13, 2005, 7:32pm

Results (SDL 1.2.8):
G5 Dual 2.0, Radeon 9800, OSX 10.3.9:
about 20k blits/s

G4 1.5 (Powerbook), Radeon 9700, OSX 10.4.0:
about 6.5k blits/s

2D blitting is all about memory bandwidth and CPU cache pressure…the
G5 is going to smoke the G4 here, regardless of OS version.

Both will go significantly faster if you use the CVS version of SDL,
too…1.2.8 didn’t have all the Altivec blitter work.

–ryan.

Derek_Bolli · May 18, 2005, 12:49am

Ryan C. Gordon <icculus clutteredmind.org> writes:

Has anybody done some blits per second tests with tiger yet? I did that
on Jaguar once and the results were quite poor compared to
windows-machines.

Hi Guys,

I’m glad (in a way) that others are seeing the same things that I am.

I have an iMac G5 1.85GHz and a 2D demo game running using spriteworldx which
uses SDL. I have a copy compiled in 10.3.9 Xcode 1.5 gcc 3.3 SDL 1.2.7 that ran
at about 100fps in an 800 x 600 window and about twice that in fullscreen mode.

I installed 10.4 and re-compiled in Xcode 2.0 gcc 4.0 and the framerate in
windowed mode dropped to about 20fps making the game unbearably slow. In
fullscreen it was faster but still not a patch on 10.3.9 performance.

The funny thing was that the copy of the game compiled under 10.3.9 Xcode 1.5
gcc 3.3 still runs under 10.4 at the old faster speed. I tried re-compiling
under gcc 3.3 in Xcode 2.0 and also upgrading SDL to 1.2.8 but game still runs
slowly.

The other funny thing is that the 10.3.9 version of the game soaks up all
available CPU but the 10.4 version rarely gets up to 10 percent of CPU and
mainly sits at 6 percent or so and I think that this throttling back effect is
the cause of the performance drop.

Great tip on trying the CVS version of SDL rather than 1.2.8. I will do this
tonight and let you know.

Thanks,

Derek Bolli, Head Hacker,
Bolli World HQ Computing Facility,
Hornsby NSW 2077
Sydney, Australia email: @Derek_Bolli (home)

Bob_Ippolito · May 18, 2005, 4:34pm

Ryan C. Gordon <icculus clutteredmind.org> writes:

Has anybody done some blits per second tests with tiger yet? I
did that
on Jaguar once and the results were quite poor compared to
windows-machines.

I’m glad (in a way) that others are seeing the same things that I am.

I have an iMac G5 1.85GHz and a 2D demo game running using
spriteworldx which
uses SDL. I have a copy compiled in 10.3.9 Xcode 1.5 gcc 3.3 SDL
1.2.7 that ran
at about 100fps in an 800 x 600 window and about twice that in
fullscreen mode.

I installed 10.4 and re-compiled in Xcode 2.0 gcc 4.0 and the
framerate in
windowed mode dropped to about 20fps making the game unbearably
slow. In
fullscreen it was faster but still not a patch on 10.3.9 performance.

The funny thing was that the copy of the game compiled under 10.3.9
Xcode 1.5
gcc 3.3 still runs under 10.4 at the old faster speed. I tried re-
compiling
under gcc 3.3 in Xcode 2.0 and also upgrading SDL to 1.2.8 but game
still runs
slowly.

The other funny thing is that the 10.3.9 version of the game soaks
up all
available CPU but the 10.4 version rarely gets up to 10 percent of
CPU and
mainly sits at 6 percent or so and I think that this throttling
back effect is
the cause of the performance drop.

Great tip on trying the CVS version of SDL rather than 1.2.8. I
will do this
tonight and let you know.

It sounds like Apple changed an implementation detail of Cocoa to
synchronize screen updates with the vertical retrace or something.
In several places, if Cocoa detects that the executable was compiled
with an earlier version of Mac OS X it will invoke the old code path
for compatibility reasons.

I’m surprised that it went all the way down to 20fps, but you should
never be drawing faster than the refresh rate… It’s a waste of CPU
and can cause tearing.

-bobOn May 17, 2005, at 8:49 PM, Derek Bolli wrote:

Richard_Schreyer · May 18, 2005, 9:49pm

There is supposedly a bug in 10.4.0 and 10.4.1 which slows down double
buffered rendering significantly. Look for more details in recent (past
week) postings on the mac-opengl and quartz mailing lists.

Richard Schreyer

Derek Bolli wrote:> Ryan C. Gordon <icculus clutteredmind.org> writes:

Has anybody done some blits per second tests with tiger yet? I did that
on Jaguar once and the results were quite poor compared to
windows-machines.

Hi Guys,

I’m glad (in a way) that others are seeing the same things that I am.

I have an iMac G5 1.85GHz and a 2D demo game running using spriteworldx which
uses SDL. I have a copy compiled in 10.3.9 Xcode 1.5 gcc 3.3 SDL 1.2.7 that ran
at about 100fps in an 800 x 600 window and about twice that in fullscreen mode.

I installed 10.4 and re-compiled in Xcode 2.0 gcc 4.0 and the framerate in
windowed mode dropped to about 20fps making the game unbearably slow. In
fullscreen it was faster but still not a patch on 10.3.9 performance.

The funny thing was that the copy of the game compiled under 10.3.9 Xcode 1.5
gcc 3.3 still runs under 10.4 at the old faster speed. I tried re-compiling
under gcc 3.3 in Xcode 2.0 and also upgrading SDL to 1.2.8 but game still runs
slowly.

The other funny thing is that the 10.3.9 version of the game soaks up all
available CPU but the 10.4 version rarely gets up to 10 percent of CPU and
mainly sits at 6 percent or so and I think that this throttling back effect is
the cause of the performance drop.

Great tip on trying the CVS version of SDL rather than 1.2.8. I will do this
tonight and let you know.

Thanks,

Derek Bolli, Head Hacker,
Bolli World HQ Computing Facility,
Hornsby NSW 2077
Sydney, Australia email: dbolli at bigpond.net.au (home)

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

Derek_Bolli · May 19, 2005, 12:45am

Bob Ippolito <bob redivi.com> writes:

I’m surprised that it went all the way down to 20fps, but you should
never be drawing faster than the refresh rate… It’s a waste of CPU
and can cause tearing.

-bob

Thanks for the info and I agree with your comments re. excessive fps.
But I am in development “let’s see how fast this baby can go mode”
spriteworldx has configurable max fps setting so I would set this to
30 or so fps before deploying.

I downloaded SDL from CVS last night and compiled and found there was
a significant (approx 75%) speed increase but not enough to make the
game playable. Might have to investigate disabling double buffering
in SDL surface in spriteworldx…

Thanks again,

Derek Bolli, Head Hacker,
Bolli World HQ Computing Facility,
Hornsby NSW 2077
Sydney, Australia email: @Derek_Bolli (home)

Derek_Bolli · May 19, 2005, 12:52am

Richard Schreyer <rws_list girr.org> writes:

There is supposedly a bug in 10.4.0 and 10.4.1 which slows down double
buffered rendering significantly. Look for more details in recent (past
week) postings on the mac-opengl and quartz mailing lists.

Hi Richard,

Thanks for the info above.

As I said in a post above, I downloaded SDL from CVS last night and compiled in
10.4.1 and found there was a significant (approx 75%) speed increase but not
enough to make my game playable. So based on your comments, I might have to
investigate disabling double buffering in the SDL surfaces in spriteworldx…

Thanks again,

Derek Bolli, Head Hacker,
Bolli World HQ Computing Facility,
Hornsby NSW 2077
Sydney, Australia email: @Derek_Bolli (home)

Derek_Bolli · May 19, 2005, 2:55am

Derek Bolli <dbolli bigpond.net.au> writes:

Hi All,

To summarize a post in mac-opengl mailing list which
references the Window Manager section of
http://developer.apple.com/releasenotes/Carbon/HIToolbox.html

It is a “feature” of coalesced updates in CoreGraphics in 10.4.x
that a drawing thread writing to a double-buffered window is
blocked from writing between the time a flush request is made
and the flush is completed i.e. the next VBL.

If the thread is drawing frames more regularly than the
refresh rate (60Hz on LCD screen) the drawing thread will
spend a significant time blocked or unable to draw and this
will significantly impact performance.

So the answer is to disable the coalesced updates in all apps
via QuartzDebug to assess performance impact and then to ensure
that drawing occurs in sync with the refresh rate/VBL.

Cheers,

Derek Bolli, Head Hacker,
Bolli World HQ Computing Facility,
Hornsby NSW 2077
Sydney, Australia email: dbolli bigpond.net.au (home)

Chris_Nystrom · May 19, 2005, 3:10am

It sounds like the right thing to do, for now, is to continue to use
the old version of the OS and tools for development until the bug is
fixed.

ChrisOn 5/17/05, Derek Bolli wrote:

The funny thing was that the copy of the game compiled under 10.3.9 Xcode 1.5
gcc 3.3 still runs under 10.4 at the old faster speed.

–
E-Mail: Chris Nystrom
Business: http://www.shaklee.net/austin
Blog: http://conversazione.blogspot.com/
AIM: nystromchris