Design Element
Comment on "Some Explanation Required, Cocoa and Carbon"
by Chris — Oct 09
Scott: two things.

1. I think the problem with Wil's post is that the thrust of his point (if you are correct in that it's just that he wants everything exposed in ObjC) is lost in his frothing at the mouth over how awful Carbon is. The tone of his post is way over the top.

2. To echo a previous poster: the Carbon event system underlies Cocoa's event handling (do a stack trace and see the variations on 'BlockNextEvent' -- those are Carbon event calls). Modern Carbon apps can be perfectly good citizens WRT CPU time, and Cocoa apps can be bad ones. iTunes is using a timer to do something requiring periodic action, the same way it would if it were a Cocoa app; it probably doesn't need to run a timer that often, but that's not Carbon's fault. My guess is it's something to do with the track name display.

BTW, on GarageBand's CPU usage: pro audio apps stream audio during the entire session, whether or not they're actually being asked to do something that involves recording or playback at any given moment. This is by design. Starting the audio hardware can be expensive, and you want to be ready to record immediately when the user presses the record button.

All of this said, I don't really see what all of the fuss is about. It's been made abundantly clear that Objective-C is the way of the future. Apple can't expose everything overnight in Objective-C; there's too much history and they don't have enough resources to do this and enormous tasks like the 64-bit transition simultaneously. Have some patience.
Back to "Some Explanation Required, Cocoa and Carbon"
Design Element

Copyright © Scott Stevenson 2004-2015