To be clear, a “Framework” is the dynamic library + headers +
resources all in one package.
Frameworks go in /Library/Frameworks.
ah ! This is quite a revelation… does such a “framework” get linked
statically ? If i distribute my program as a simple one-file-
appliction, will it find these frameworks ? Or are they like DLLs and
do they have to be distributed alongside the app ? (newbie to mac
here… really sorry if i ask stupid questions)
No, this is a good question. Frameworks are like a DLL. They are
dynamically linked in. This is actually nice when dealing with
licenses like the LGPL.
But to avoid having a mess of files installed all over the system and
avoid possible conflicts (a.k.a dll-hell), Mac has a ‘bundling’
convention where all necessary components can go inside to constitute
a single package. For applications, this is often referred to as an
’.app bundle’ or application bundle. If you dissect a good (Cocoa
based) application, you will see it just looks like a single file in
Finder. But if you go to the Unix command line, you will see it is
actually a directory structure containing a bunch of things including
the underlying executable and resources (icons, images, sounds,
localizations, etc). It may also contain dynamically linked libraries
inside which could be SDL. So to the end-user, it the application
looks like a single file which can be drag-and-dropped anywhere. But
to the developer, this is where you put all your stuff.
(Frameworks themselves are actually a bundle because they are just a
directory structure organized in a special way that contains the
underlying dynamic libraries, the header files, and any resources if
applicable.)
So when you deploy your app, you should bundle it with SDL. This way
the user doesn’t need to worry about installing additional
dependencies. This is similar to statically linking except that you
get the benefits of dynamic linking, such as potentially less pain
when dealing with the LGPL.
This thread which also asked the same thing and it just had a follow
up today. You might want to look at it.
http://lists.libsdl.org/pipermail/sdl-libsdl.org/2007-October/063084.html
Also, I recommended watching the screencast tutorials I made for
OpenSceneGraph which go into detail about how to get started with
Frameworks, Xcode, and bundling.
http://www.openscenegraph.org/projects/osg/wiki/Support/Tutorials/MacOSXTips
too bad the FAQ & docs still point to the old locations… who manages
these files ? Maybe I could help him out by mailing him the new
locations…
The documentation that comes in the official packages was provided by
me. I know this is an issue, but the last SDL release predates Leopard
so we couldn’t talk about it. I sent some different changes to Sam
some weeks ago but still haven’t heard back. I’m waiting on this
before I submit any more changes.
PS to eric : you seem to be quite an authority here…
Kind of, sort of, not really.
can you shed
some light on the gdb console message I was talking about :
2007-11-09 23:33:19.573 ?PROJECTNAME?[2332:813] Warning once: This
application, or a library it uses, is using NSQuickDrawView, which has
been deprecated. Apps should cease use of QuickDraw and move to Quartz.
will this have a performance hit ?
Yes, no, maybe, it depends. So first, SDL is supposed to shelter you
from a lot of the details. For just getting started, I wouldn’t worry
myself about these things. However, if you need serious hardware
performance and more low level control, then you might consider OpenGL
instead.
Performance is hard to characterize at this high level. Also note that
hardware is not always faster than software. I think there is an SDL
FAQ item on hardware surfaces vs software surfaces and for the common
case, software usually wins I think. There are a bunch of reasons for
this I don’t want to get into here. Search the archives.
Performance may also depend on which version of OS X you are running
on. First, OS X uses a fully compositing graphics system, meaning
applications don’t get direct access to the framebuffer and everything
must go through a single service (Quartz Compositor) whose job is to
combine all the backing stores into a final image. A lot of different
things can happen here, shadows, alpha blending, anti-aliasing, etc.
But the point is that you don’t have direct access to the hardware and
you should consider everything virtualized.
QuickDraw is Mac classic technology (predating Quartz/OS X) and used
the draw to hardware idea. This obviously doesn’t mesh well with
Quartz and my guess is that Apple had to do some nasty things to get
the two to play together.
Speedy was not something used to describe Quartz in early versions of
OS X. On of the problems was that Quartz anti-aliases everything to
look nice while QuickDraw bypassed all that on the system. So early
on, people who needed speed still coded in QuickDraw against Apple’s
warnings.
But then Apple started optimizing Quartz and pushing more of the
responsibilities onto OpenGL to get hardware acceleration. Since then
Quartz’s performance caught up to QuickDraw and in most cases exceeded
QuickDraw by far.
And Apple is trying to do a lot of different things with the graphics
system like Resolution Independent UI. These things don’t gel well
with QuickDraw. But since OS X, it’s been well known QuickDraw was a
goner. So here we are 7 years later.
As for what SDL is doing with QuickDraw, I’m actually not sure. But
your performance might vary depending on which version of OS X you run
and what kind of drawing you do and how much.
I’m expecting that SDL 1.3 will remove/rewrite deprecated code if it
hasn’t already been done.
But again, I would say, don’t worry too much about it getting started.
SDL performance is generally good. If not, profile and find out where
the real problems exist. I’m actually expecting that things like
Resolution Independent UI (if it ever ships) will not work correctly
if we are using QuickDraw, but I’m not familiar enough with the code
to say. It could be that the QuickDraw code is rarely used. And
ultimately you might also be able to move to SDL 1.3 when it becomes
ready and you have problems.
Ars Technica article on Quartz in Tiger:
-EricOn 11/10/07, jeroen clarysse <jeroen.clarysse at telenet.be> wrote:
