[Pythonmac-SIG] Announce: PythonCard 0.3.1 - need wxPython on the Mac
Donovan Preston
dpreston@intersight.com
Fri, 10 Aug 2001 14:16:18 -0700
On Friday, August 10, 2001, at 01:44 PM, Joe Graham wrote:
> Hello,
> Let's change gears for a moment shall we?
> First as per this:
>> No: Carbon apps have Aqua controls under OSX.
> Carbonized apps can have the "Aqua" l&f under mac
> classic. However there is a heavy price to pay for
> "Carbonized" applications. Not sure about what the
> next release from hell from apple will do for
> performance there but it's hideous on OSX.
While this is true for most Carbon apps, the performance problems are
really the fault of old style loop & poll programming in which most Mac
apps have been written since 1984. Since pre-Mac OS X was not
preemptively multitasking, it made sense for traditional apps to be
programmed in this style, since they would only get the processor when
they were in the foreground or if they really needed it in the
background. However, under a preemptively multitasking OS like X, this
breaks down horribly, because all of those carbon apps look like they
are doing a ton of work when in reality they are just burning cycles
looking for events to process. Since Mac OS X has to decide which
application gets the processor by gauging each processes' processor use,
if carbon apps were allowed to run amuk, they would burn all the
processor time basically doing nothing.
To remedy this and make OS X even usable, Apple had to do something.
This is *entirely speculation* given my experience with current carbon
apps and some process monitoring tools, but it appears that apple
basically limited carbon applications to 50% of the processor. This
would go a long way towards explaining carbon's current poor
performance, as well as X's ability to run background tasks at close to
full speed while another process is executing.
HOWEVER, there is another solution, which I suspect most Carbon
application developers have not pursued yet because it involves a
significant amount of rewriting on their part. This solution is the
Carbon Event Manager. It is basically an event callback based system, in
which your application's main thread of execution is sleeping somewhere
deep in the bowels of the system while your application is idling, and
then as soon as an event that affects your application occurs, your
application receives a callback, gets a chance to process the event, and
then goes back to sleep. Once more carbon developers start getting off
their lazy butts and rewrite their application's main event loops to
behave better in a modern operating environment things will get a lot
better.
Remember, Apple delayed the release of Rhapsody by quite a few years
just to satisfy it's developers and port the Mac OS toolbox to Mac OS X.
Microsoft had most of the 1990's and three major releases to port it's
win32 api to NT, and while things are better with 2000, there are still
a lot of applications that don't run (mostly games and audio software)
on Microsoft's "New Technology" OS.
Donovan