OS-X: Carbon event handling

This may be opening a can of worms, but I’m wearing my Nomex suit, so
I shall ask anyway:

Why do the OS-X bits of SDL use Cocoa, instead of Carbon? I’ve been
looking over the code, and as far as I can see, using Cocoa causes
nothing but complications, particularly the need for the SDLmain
stuff and the strange way the event loop gets run. Every time a I
debug an SDL app I’m a bit troubled by the the state of the bottom of
the stack.

From what I can tell, a pure Carbon and C implementation of the
event code using ReceiveNextEvent would be entirely doable; the
major obstacle I can see is that most of the code in video/quartz
would need to be moved over from Cocoa calls to their Carbon
equivalents, but that’s not a huge amount of code in total, and I
notice various places where ‘Core’ calls are already inter-mixed with
the Cocoa code; eg calls to CGL functions in QDL_QuartzGL.m.

(…looking over the code some more …)

In fact, SDL_QuartzVideo.m seems to confirm my point even more than I
realized: most of the key code is CoreGraphics, Quickdraw or CSG
calls, with a very few NSxxx calls inter-mixed, and at one least
comment indicating a work-around for a bug where Cocoa and
CoreGraphics don’t synchronize something correctly.

By the way, I love Cocoa, but all the things it’s designed for (and
good at) are irrelevant to SDL, and some of the things SDL wants to
do are ‘unusual’ in Cocoa.

I would be happy to do more investigation on this, and the bulk of
coding, but of course there’s a lot of time and effort invested in
the current Cocoa-based code, so I won’t bother unless the SDL mac
contributors (I guess that means Eric Wing and Ryan Gordon, and
anyone else with a strong opinion) agree this is worth pursuing, at
least as an experiment. I would love to see SDLmain.m and the
applicationDidFinishLaunching magic die a quick, but maybe no one
else is that bothered :slight_smile:

Please let me know if this might be contemplated (for 1.3.x,
naturally), and what criteria would be necessary for people to
consider using it. I don’t think a basic proof-of-concept would take
long to get off the ground, but I’d sooner not spend time on it, if
people think this is a silly idea.

Regards,
James

James Turner wrote:

Why do the OS-X bits of SDL use Cocoa, instead of Carbon?

I guess the reason is that the people who worked on it are fluent in
Cocoa, can deal with CoreFoundation and CoreGraphics-like stuff, but are
utterly unfamiliar with Carbon. At least, that’s the case for me. :slight_smile:

However, I think there is a Carbon backend, and I faintly remember
hearing that it works on Mac OS X. I’ve never used it, though. The guy
to ask about this would be Anders F. Bj?rklund
(http://www.algonet.se/~afb/libsdl/). I guess you should be able to find
out some things by reviewing his postings to this mailing list:
http://search.gmane.org/?query=&email=afb%40algonet.se&group=gmane.comp.lib.sdl&sort=date

…Quickdraw…

The QuickDraw stuff should probably be replaced some time, see
https://bugzilla.libsdl.org/show_bug.cgi?id=108 .

…at one least comment indicating a work-around for a bug where
Cocoa and CoreGraphics don’t synchronize something correctly.

I’m not sure if anyone has recently checked whether that bug is still
present in the versions of Mac OS X we support (10.2+). There were even
some workarounds for bugs in Mac OS X Public Beta in the code until
recently…

I would love to see SDLmain.m and the applicationDidFinishLaunching
magic die a quick, but maybe no one else is that bothered :slight_smile:

I’ve gotten used to being able to hook up my menus in Interface Builder,
use Cocoa alerts and file dialogs, and even display auxiliary windows
using Cocoa - would we lose these abilities (or any of their ease) in a
Carbon backend?

-Christian

The QuickDraw stuff should probably be replaced some time, see
https://bugzilla.libsdl.org/show_bug.cgi?id=108 .

Interesting, and worth thinking about for sure.

…at one least comment indicating a work-around for a bug where
Cocoa and CoreGraphics don’t synchronize something correctly.

I’m not sure if anyone has recently checked whether that bug is still
present in the versions of Mac OS X we support (10.2+). There were
even
some workarounds for bugs in Mac OS X Public Beta in the code until
recently…

I wasn’t sure what versions of OS-X were officially supported, but as
you say, it’s likely some work-arounds are no longer needed.

I would love to see SDLmain.m and the applicationDidFinishLaunching
magic die a quick, but maybe no one else is that bothered :slight_smile:

I’ve gotten used to being able to hook up my menus in Interface
Builder,
use Cocoa alerts and file dialogs, and even display auxiliary
windows
using Cocoa - would we lose these abilities (or any of their ease)
in a
Carbon backend?

This could be made to work in Carbon, but I hadn’t planned on it -
if you’re using Interface Builder and Cocoa, why are you using SDL in
the first place?! My concern is all the open-source projects that
don’t have or want any Mac specific code. If you’re simply using SDL
as a helper within Cocoa, I think something is amiss anyway;
wouldn’t a regular NSView and Cocoa event handling suit you better
than the SDL event model? As it stands right now, your Cocoa
auxiliary windows are running in a very odd way, since the top-level
NSApplication event loop is bypassed by the SDLmain code.

I suspect the real solution if you care about using SDL that way
would be an explicit Cocoa video device that creates a specialised
NSView subclass, and then extracts events from that view explicitly.
This is basically what the current code in video/quartz does, but I
think a video backend designed for the job would be simpler, since it
could rely on more Cocoa things operating ‘normally’, and presumably
wouldn’t need the video mode switching or full-screen support, unless
you are doing something /really/ odd with SDL.

That said, I don’t think it’s a good tradeoff for every cross-
platform SDL app on OS-X to need Cocoa, given the resulting issues,
purely to support this use case. Of course, if all your care about is
showing some alerts and NIB-based dialogs, that can be done from
Carbon easily enough, but you still need another solution for Windows
and Linux and …

H&H
JamesOn 5 Apr 2006, at 18:38, Christian Walther wrote:

Some people, when confronted with a problem, think ?I know, I?ll use
regular expressions.? Now they have two problems.

James Turner wrote:

I’ve gotten used to being able to hook up my menus in Interface Builder,
use Cocoa alerts and file dialogs, and even display auxiliary windows
using Cocoa - would we lose these abilities (or any of their ease) in a
Carbon backend?

This could be made to work in Carbon, but I hadn’t planned on it - if
you’re using Interface Builder and Cocoa, why are you using SDL in the
first place?!

Alerts and file dialogs aren’t provided by SDL, so I have to do these in
platform-specific code - I’m using Cocoa on Mac OS X, GTK on X11, win32
on Windows. About the menus - I just think it’s nice to be able to do
things like “Open saved game…” from a menu on the Mac, since the menu
bar is there anyway. The auxiliary window I mentioned just displays
debug information while I’m developing on my home platform Mac OS X, it
isn’t used in the final product that also runs on Linux and Windows.

My concern is all the open-source projects that don’t have or want any Mac specific code.

Just out of curiosity, what’s the problem with those and the Cocoa
backend? They don’t have to use SDLMain.nib or anything if they don’t
want to. As long as they can deal with SDL wrapping up their main()
function (which AFAIK also happens on other platforms), everything
should be fine?

As it stands right now, your Cocoa auxiliary windows are running
in a very odd way, since the top-level NSApplication event loop is
bypassed by the SDLmain code.

I actually wondered about this too, but it seems to work well - the
periodic [NSApp nextEventMatchingMask: …] and subsequent [NSApp
sendEvent:event] done through SDL_PollEvent() seems to be sufficient to
keep the window alive. Again, I’m not depending on this in a released
product - I just tried it and was pleasantly surprised that it worked.

That said, I don’t think it’s a good tradeoff for every cross-platform
SDL app on OS-X to need Cocoa, given the resulting issues, purely to
support this use case.

Care to elaborate on what your “issues” are? I haven’t had any with the
few Mac-agnostic SDL apps I’ve compiled.

Of course, if all your care about is showing some alerts and NIB-based dialogs, that can be done from Carbon easily enough

OK, that’s actually what I expected, so I’m not too worried about this.
Is any initialization work other than setting up an NSAutoreleasePool
required to use Cocoa in a Carbon app? (That’s a rhetorical question, I
should be able to find the answer to that myself easily.)

-Christian> On 5 Apr 2006, at 18:38, Christian Walther wrote:

Christian Walther <cwalther gmx.ch> writes:

Just out of curiosity, what’s the problem with those and the Cocoa
backend?

That said, I don’t think it’s a good tradeoff for every cross-platform
SDL app on OS-X to need Cocoa, given the resulting issues, purely to
support this use case.

Care to elaborate on what your “issues” are? I haven’t had any with the
few Mac-agnostic SDL apps I’ve compiled.

I have just been grappling with this recently myself. I am using Lisp (SBCL)
and SDL on OS X. On all other platforms, this is reasonably easy because SDL is
plain C for the most part. However the Cocoa wrapper on OS X causes headaches,
partly because the SDL wrapper expects to exit when SDL_main returns. In an
interactive Lisp environment you want to bring a window up, do some stuff
(perhaps interactivly) maybe close the window and start again. All without
leaving the Lisp image. Python needs to jump through similar hoops - infact I
copied the way that Python does it.
In short, I think that any non-basic-c applications of SDL on OS X will probably
suffer because of the Cocoa backend.

Assuming Carbon makes all or most of this pain go away, then I would really like
to see a Carbon backend & would be willing to help where I can.

Cheers
Brad

I have just been grappling with this recently myself. I am using
Lisp (SBCL)
and SDL on OS X. On all other platforms, this is reasonably easy
because SDL is
plain C for the most part. However the Cocoa wrapper on OS X
causes headaches,
partly because the SDL wrapper expects to exit when SDL_main
returns. In an
interactive Lisp environment you want to bring a window up, do some
stuff
(perhaps interactivly) maybe close the window and start again. All
without
leaving the Lisp image. Python needs to jump through similar hoops

  • infact I
    copied the way that Python does it.
    In short, I think that any non-basic-c applications of SDL on OS X
    will probably
    suffer because of the Cocoa backend.

Urk, that’s a pretty nasty scenario. I dread to think what the code
you borrowed from Python looks like. And yes, this sort of thing is
exactly why I think it would be good for SDL-OSX to fit better with
the SDL event / mainloop model. Based on what you describe, I think
this should work ‘better’ with Carbon: all the event processing
would happen inside SDL_PollEvent, so you could run as many loops as
you like. Of course I don’t know what the Lisp environment on OS-X is
doing with the system event queue, but any issues should be the same
for Cocoa or Carbon.

I think it would be interesting to at least prototype this - I’m
inclined to do so as a mod to 1.2.9 (so I can test existing SDL apps
with a drop-in framework replacement). I’ll try to assemble my
thoughts on doing the prototype, and post them tomorrow.

Regards,
JamesOn 10 Apr 2006, at 22:36, Brad Beveridge wrote:

There is no such thing as a humble opinion.

SDL_PollEvent, so you could run as many loops as you like. Of course I don’t
know what the Lisp environment on OS-X is doing with the system event queue,
but any issues should be the same for Cocoa or Carbon.
SBCL, at least, really only uses console i/o, so I don’t think that it
should interfere with the event loop at all. Though, I haven’t used
Cocoa really at all before - so who knows? :slight_smile:

I think it would be interesting to at least prototype this - I’m inclined to
do so as a mod to 1.2.9 (so I can test existing SDL apps with a drop-in
framework replacement). I’ll try to assemble my thoughts on doing the
prototype, and post them tomorrow.
Cool. I’d be willing to test.

BradOn 4/10/06, James Turner wrote:

First, I thought somebody already recently fixed up the Carbon
backend. You should look into that. I did not do anything for the
Xcode build system for this, but I think it might be in the autoconf
system. This will hopefully save you work and testing.

Second, I personally like the Cocoa stuff for many of the same reasons
Christian mentioned. Though SDL code has a focus on being portable,
but I don’t think it’s intended to prevent you from polishing your app
to better work with the native host. (I think I recall Ryan recently
added something to allow drag-and-drop onto the app’s dock icon.) SDL
is also a very good candidate for (rapid) prototyping where
portability may not be the primary concern. How many times has the
WindowID hack been asked about for Windows? I think the SDLMain.m
architecture gives OS X developers a lot of this kind of flexibility.

More to my paranoia than hard facts, I also worry about Carbon
support. I get the feeling Apple only keeps it around for Adobe and
Microsoft and would kill it if not for those two. As the platform
continues to evolve, we’re seeing a lot of enhancements and updates to
Cocoa, but Carbon seems to lag behind. And on their 5th major release,
there continue to be rough spots where Cocoa and Carbon don’t mix.
This all worries me a bit. On flip side, Cocoa continues to get cool
enhancements which makes developing in Cocoa much easier. For example
QuickTimeKit was a very welcome addition. I hope to see the same for
CoreAudio and other components. I would hope that future iterations of
SDL might be able to leverage this stuff to shrink the code base and
make it easier to write and maintain.

But I am not familiar with your specific issues so maybe Carbon is a
better fix. However, is it possible to modify/fix the SDLmain to
better handle the exit condition mentioned?

I should also add the disclaimer that I’m not the guy who wrote and
maintains most of the OS X code base. I’ve been doing only minor code
maintenance things. Most of my efforts have been trying to keep the
build system, binaries, and documentation up-to-date. So my opinion is
less important :slight_smile: However, I find that for what code I do end
modifying, it’s been easier to work with Cocoa than Carbon.

Thanks,
Eric

I ought to add that I have very little experience with Lisp or OS X
(hence both Carbon and Cocoa). For more info on what Python had to
do, and I had to copy, Google for CPSEnableForegroundOperation

Cheers
Brad

First, I thought somebody already recently fixed up the Carbon
backend. You should look into that. I did not do anything for the
Xcode build system for this, but I think it might be in the autoconf
system. This will hopefully save you work and testing.

Thanks, I’ll look into that.

Second, I personally like the Cocoa stuff for many of the same reasons
Christian mentioned. Though SDL code has a focus on being portable,
but I don’t think it’s intended to prevent you from polishing your app
to better work with the native host. (I think I recall Ryan recently
added something to allow drag-and-drop onto the app’s dock icon.) SDL
is also a very good candidate for (rapid) prototyping where
portability may not be the primary concern. How many times has the
WindowID hack been asked about for Windows? I think the SDLMain.m
architecture gives OS X developers a lot of this kind of flexibility.

I’ll address this point below.

More to my paranoia than hard facts, I also worry about Carbon
support. I get the feeling Apple only keeps it around for Adobe and
Microsoft and would kill it if not for those two. As the platform
continues to evolve, we’re seeing a lot of enhancements and updates to
Cocoa, but Carbon seems to lag behind. And on their 5th major release,
there continue to be rough spots where Cocoa and Carbon don’t mix.
This all worries me a bit. On flip side, Cocoa continues to get cool
enhancements which makes developing in Cocoa much easier. For example
QuickTimeKit was a very welcome addition. I hope to see the same for
CoreAudio and other components. I would hope that future iterations of
SDL might be able to leverage this stuff to shrink the code base and
make it easier to write and maintain.

This could quickly get subjective, but I’ll try to keep it factual.
The issue is that Carbon and Cocoa are not symmetric equals on OS-X -
Cocoa is much more high level, and has many, many features that make
it ideal for writing rich, modern applications. Unsurprisingly, this
means all the new Apple applications are written in Cocoa, and hence
people often assume Carbon is a temporary shim to keep Adobe and
Microsoft Office working. To compare with Linux, Cocoa would be like
Qt, and Carbon would be like Motif.

This is fundamentally not the case.

The correct analogy is that Cocoa is like Qt, but Carbon is
equivalent to X11. Sure, you can write a desktop app in raw X11, but
very few people would. But, if SDL used Qt on Linux, instead of raw
X11 calls, I think everyone would agree that would also be strange.
Indeed, if SDL did use gtk or Qt, the main loop would have exactly
the same problem mapping to the SDL event API that the Cocoa backend
does!

And sure, if the Linux port used Qt instead of raw X11, it would be
easy to make SDL interoperate with GUI written in Qt … but that’s
not a good enough reason to make SDL use Qt on linux.

Significantly, the Qt OS-X port (which I use every day at work) is
written in nothing but Carbon. And Cocoa itself uses Carbon
internally for things like drawing the menus. So you need to think of
Carbon not as an orphaned, legacy GUI toolkit, but as the low-level
access to the OS, that bypasses most of the heavy-weight (and
powerful) abstractions of Cocoa. It just so happens that, like X11,
it also contains some rather ancient GUI things (the original Mac
Toolbox). Those might go away one day (indeed, Carbon HIViews
obsolete them), but those aren’t the pieces of Carbon that SDL needs
to use, any more than SDL for X11 uses the Xt widgets.

Keep in mind that the entire ‘critical’ heart of video/quartz/
quartz_video.m is basically written in CoreGraphics calls anyway;
these aren’t going to change in a Carbon version. Other pieces of the
OS-X code already use Carbon calls, so I think that makes your
paranoia a bit hard to justify.

Btw, in the entire discussion above, you can also replace ‘Qt’ with
’MFC’ or ‘.Net’ and ‘X11’ with ‘the Win32 platform SDK’. Again, SDL
for windows uses the platform calls directly, not MFC or any other
high-level abstraction. And whatever Microsoft might like, the Win32
platform API is not going anywhere - the .net runtime sits on top of
it, it does not replace it.

To take the example of CoreAudio, Apple may one day produce a lovely,
easy to use wrapper for it in Cocoa - but does that help SDL? A
cocoa API would undoubtedly be full of rich, persistent objects,
where you define ‘NSSample’ or ‘NSChannel’ objects, hold onto them
and generally uses them as long-lived objects. None of which is
relevant to the SDL API, and cannot be exposed through it. The
current CoreAudio API is low-level, and a bit brutal in places, but
provides very precise control - exactly what SDL needs.

Now, to address the issue of using SDL for prototype apps, or showing
Carbon or Cocoa UI, I present the following document:

http://developer.apple.com/documentation/Cocoa/Conceptual/
CarbonCocoaDoc/carboncocoa.pdf

In summary, since 10.2, the event loops are bound together. You can
write a C function which calls into Cocoa code, and do absolutely
anything you like - load NIBs, show NSViews, etc.

Right, that’s enough from me. Once i have something to show for a de-
Cocoa-ified SDL, I’ll post more.
JamesOn 11 Apr 2006, at 02:04, E. Wing wrote:

First, I thought somebody already recently fixed up the Carbon
backend. You should look into that. I did not do anything for the
Xcode build system for this, but I think it might be in the autoconf
system. This will hopefully save you work and testing.

I’ve just looked over the code in video/maccommon, video/macrom and
video/macdsp (I’m assuming this is what you are referring to, since I
can’t see anything else). It brings back happy memories of
programming the original toolbox, Quickdraw and DrawSprocket.
However, it is essentially an antique at this point - while there are
#ifdefs to make it build on OS-X, it’s still using APIs that are
being killed off. Every second toolbox call is deprecated. The code
still has 68k assembler glue in places!

So something else to consider might be removing these backends from
CVS, since I can’t imagine many people are targeting OS-9 these days.
Or 68k macs :slight_smile:

Regards,
JamesOn 11 Apr 2006, at 10:45, James Turner wrote:

So something else to consider might be removing these backends from CVS,
since I can’t imagine many people are targeting OS-9 these days. Or 68k macs
:slight_smile:

I’m trying to target Mac OS 9! Even having some limited success, although
I can’t get OpenGL to work (nor testgl), nor hardware surfaces.

No 68k though :slight_smile:

Is there a maintainer for SDL/Mac OS 9?

GregoryOn Tue, 11 Apr 2006, James Turner wrote:

So something else to consider might be removing these backends from CVS,
since I can’t imagine many people are targeting OS-9 these days.

Well, I for one would like to keep it around, even if don’t have any
Apple hardware at all. Just judging by the number of games listed as
available for MacOS, they apear to be more than those targeting *BSD :wink:
And I hope I am far from the only SDL user who is more concerned over
writing fun and playable games than the framerate…

Or 68k macs :slight_smile:

Now THIS is a whole other story…On Tue, 11 Apr 2006, James Turner wrote:

Just a follow up from my situation. Writing the SDL backend in Carbon
will not solve the problem where the window doesn’t come to the front,
and doesn’t accept events. The issue is that running out of a Lisp
(or any console based interpreter) image does not work properly, you
need to make calls like.
void osx_foreground ()
{
ProcessSerialNumber processSerialNum;
GetCurrentProcess(&processSerialNum);
CPSEnableForegroundOperation (&processSerialNum, 0, 0, 0, 0);
SetFrontProcess(&processSerialNum);
}
This creates a dock icon and lets the SDL window (either Carbon or
Cocoa) come to the fore.

Cheers
Brad

This was hard to google for, so here are some keywords:
OS X OSX Carbon Cocoa Window fore foreground Lisp interpreter SDL OpenGL dockOn 4/11/06, Mattias Karlsson wrote:

On Tue, 11 Apr 2006, James Turner wrote:

So something else to consider might be removing these backends from CVS,
since I can’t imagine many people are targeting OS-9 these days.

Well, I for one would like to keep it around, even if don’t have any
Apple hardware at all. Just judging by the number of games listed as
available for MacOS, they apear to be more than those targeting *BSD :wink:
And I hope I am far from the only SDL user who is more concerned over
writing fun and playable games than the framerate…

Or 68k macs :slight_smile:

Now THIS is a whole other story…


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

void osx_foreground ()
{
ProcessSerialNumber processSerialNum;
GetCurrentProcess(&processSerialNum);
CPSEnableForegroundOperation (&processSerialNum, 0, 0, 0, 0);
SetFrontProcess(&processSerialNum);
}
This creates a dock icon and lets the SDL window (either Carbon or
Cocoa) come to the fore.

The better fix for this is to make a proper bundle, then the
CPSEnableForegroundOperation hack should no longer be necessary. But
it’s useful to have it for debugging and other edge cases.

JamesOn 17 Apr 2006, at 15:52, Brad Beveridge wrote:

Right, that’s enough from me. Once i have something to show for a de-
Cocoa-ified SDL, I’ll post more.

Make sure you work with CVS code, it’s been totally revamped from 1.2.9.
Also, I’d appreciate it if you have a chance to look at all the deprecated
API’s that we get warnings for on Mac OS X 10.4

Thanks!
-Sam Lantinga, Senior Software Engineer, Blizzard Entertainment

Make sure you work with CVS code, it’s been totally revamped from
1.2.9.
Also, I’d appreciate it if you have a chance to look at all the
deprecated
API’s that we get warnings for on Mac OS X 10.4

I made a start on this (I have the basic event mapping from Carbon
Events through to SDL_PrivateFoo written) but got side-tracked by
more pressing things and the general lack of enthusiasm.

In terms of deprecated APIs, well that’d be because the ‘Cocoa’ code
still goes back to Quickdraw for non-OpenGL mode! As I understand it,
the calls to LockPortBits and the like just bring the WindowServer
and CoreGraphics screeching to a halt, with the drawing pipeline
being flushed and every overlapping window being recomposited in
funky ways. Presumably this is worse on Tiger, where rendering as
well as compositing is pipelined through to the hardware.

In the long-term, the approach I would like to take (and the only I
can think of that is compatible with the future direction of
CoreGraphics) is to always make SDL software drawing render to a
memory buffer, and to create a CGImage from that each time a buffer
swap is requested - this is also what Apple suggest for direct access
to the rendering context. Even on the slowest iMac or iBook, such
approach should be plenty fast enough, and means the client code
using SDL can see a nice palettised or 24-bit, randomly-sized
surface, with or without alpha. An additional advantage would be that
any upscale during the blit can be filtered in hardware by CoreGraphics.

Anyway, once I get back to this, I’ll start doing it against CVS, not
1.2.9, and also track down which deprecated functions are easy to get
rid of, and which require the (somewhat intrusive!) change describe
above.

H&H
JamesOn 17 Apr 2006, at 17:29, Sam Lantinga wrote:

In the long-term, the approach I would like to take (and the only I
can think of that is compatible with the future direction of
CoreGraphics) is to always make SDL software drawing render to a
memory buffer, and to create a CGImage from that each time a buffer
swap is requested - this is also what Apple suggest for direct access
to the rendering context. Even on the slowest iMac or iBook, such
approach should be plenty fast enough, and means the client code
using SDL can see a nice palettised or 24-bit, randomly-sized
surface, with or without alpha. An additional advantage would be that
any upscale during the blit can be filtered in hardware by CoreGraphics.

Anyway, once I get back to this, I’ll start doing it against CVS, not
1.2.9, and also track down which deprecated functions are easy to get
rid of, and which require the (somewhat intrusive!) change describe
above.

Thanks!
-Sam Lantinga, Senior Software Engineer, Blizzard Entertainment

In the long-term, the approach I would like to take (and the only I can
think of that is compatible with the future direction of CoreGraphics)
is to always make SDL software drawing render to a memory buffer, and to
create a CGImage from that each time a buffer swap is requested - this
is also what Apple suggest for direct access to the rendering context.
Even on the slowest iMac or iBook, such approach should be plenty fast
enough, and means the client code using SDL can see a nice palettised or
24-bit, randomly-sized surface, with or without alpha. An
additional advantage would be that any upscale during the blit can be
filtered in hardware by CoreGraphics.

I think this is the right way to go, but every time I sit down to attack
it, my spirit is broken by the Apple documentation. :slight_smile:

I think this is way more important than moving from Cocoa to Carbon…it
happens to work fine on Tiger, but the performance implications for
Leopard are still an unknown, so this has to get rewritten in the next
six months or so, I think.

–ryan.

James Turner wrote:

Make sure you work with CVS code, it’s been totally revamped from 1.2.9.

Also, I’d appreciate it if you have a chance to look at all the deprecated

API’s that we get warnings for on Mac OS X 10.4

I made a start on this (I have the basic event mapping from Carbon
Events through to SDL_PrivateFoo written) but got side-tracked by more
pressing things and the general lack of enthusiasm.

Re: ‘general lack of enthusiasm’, I’d like to say that I’ve jumped
through the hoops nessesary to get something that uses SDL exported to a
scripting language in Mac OS X and I’d love to see this cleaned up :-).

Regards,

Uli> On 17 Apr 2006, at 17:29, Sam Lantinga wrote: