[Pythonmac-SIG] Announce: PythonCard 0.3.1 - need wxPython on the Mac

[Donovan Preston]

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