I'm not a programmer but I don't believe there are speed differences. My experiences lead me to believe that good Carbon and Cocoa coding beat sloppy programming any day.
It is possible to wrap some Carbon coding into Cocoa objects I think.
added: Also, Carbon seems to be given its poor repute thanks mainly to ports of older applications that don't use Carbon Events, among other things. Seems like the biggest Carbon anti-heroes (like the Finder) use the old method of WaitNextEvent and stuff like that, not to mention that they comile them differently and don't bother to dice them up as threads.
<strong>HIt's just so often when I read "Man! Can you imagine how much FASTER this will be when they write it for Cocoa??"</strong><hr></blockquote>That's because, to put it bluntly, those people are non-programmer morons who've jumped on the closest bandwagon to complain about something they don't understand.
[quote]<strong>If they're writing it for Cocoa - will they have to re-write everything?</strong><hr></blockquote>Not necessarily *everything* but, yes, certainly a vast majority of code. [quote]Originally posted by BuonRotto:
<strong>It is possible to wrap some Carbon coding into Cocoa objects I think.</strong><hr></blockquote>Correct. QuickTime for example is Carbon yet it can work just fine in Cocoa apps.
All in all, people just mistakenly think that Carbon is bad because they've seen so many bad Carbon ports. That's the fault of the programmers, not necessarily Carbon. Carbon code requires a bit more writing than Cocoa, but as Amorph said if you write the code using the correct *newer* models, then you can get a great app.
<strong>Is carbon not as multi-threaded as cocoa?</strong><hr></blockquote>Well, I wouldn't say that. Carbon can be as threaded as any Cocoa app, with some small exceptions I can't recall, but you're just seeing another case where developers haven't completely moved over to the newer event model. QuickTime Player, for example, is a Carbon app and will keep playing movies while you hold the mouse down. Audion, another Carbon app, processes the addition of files to the playlist, <a href="http://brad.project-think.com/movies/audion-with-menus.mov"; target="_blank">constantly updating while you mouse down through the menus</a>.
I'm probably wrong, but I was under the impression that things like the mouse button hang were due to the old Mac OS Toolbox model where it bombards the system with calls to find out what has changed. The Carbon Event model will tell the app what has changed when it has changed, thus avoiding the bagillion calls the system has to process.
Correct. Carbon is as sophisticated or as primitive as you tell it to be. The Carbon programmer has a tremendous amount of control over the nature and performance of her application, which implies a tremendous amount of responsibility. The Cocoa programmer has a lot of work done for her behind the scenes.
Snapz Pro X is an excellent example of what a Carbon app can be if the developer exploits its potential.
Finder has the additional problem of being a proof of concept for MetroWerks' PowerPlant class libraries, so as with Cocoa apps it will "magically" improve as MetroWerks improves their port of the PowerPlant classes.
Note that it is possible for a Carbon app to be better threaded than a Cocoa app. Much of Cocoa's AppKit is not reentrant (meaning that it's not safe to make calls to the same method within multiple threads at once), and as a result there is an awkward arrangement built into the application frameworks where only one thread draws into the view (the window, essentially), and this thread also contains the main event loop. This is why Cocoa windows stop rendering when you hold the mouse down on the scrollbar thumb (but only that window stops updating, not the whole app or the whole system). It's quite possible to make a Carbon app that doesn't exhibit that behavior.
I am developing apps using Cocoa now and am pretty new to it. But the latest April Dev Tools release has GCC 3 compiler that is definately going to speed/optimize that apps to be about 10% faster regardless of how well or crappy your implementation is. Using the Thread safe libraries for multithreading is definatley something where key parts of the cpu intensive app can be optimized. Also, you can use Omni Groups ObjectMeter which can help track and identify key parts of your app where you can optimize especially for the allocation of objects as well CPU intensive objects that render/draw, etc.
Lastly, they key project which is awesome is the Apple Seed project which can help you run an app in a *clustered* environment. This means that a program like BLAST from Genetech can run on a farm of XServers utilizing not just dual processor systems but a farm of dual processors systems in a clustered environment. There is an sample of this called Pooch.
So, here are the four main areas where apps can be optimized to their max potential:
1. Implementation of code
2. AltiVec enhanced (utilize the G4). not all do this.
3. Multithread the app
4. Enble clustering (via Pooch/AppleSeed)
(This is like how SETI is run for example)
I like Cocoa a lot. It save me time doing the mundane stuff over and over by using the App or Foundation Kits but also other frameworks. Learning the APIs/Frameworks and the concept of Model View Controller and message passing in OO takes some getting your head wrapped around but once you are through it, its awesome (IMHO). I also like ObjC, its just like C. It has some danger points in that its loosly typed (id) but you can make it strongly typed if you want. Also, you have to watch out for garbage collection and releasing objects, and memory management which can cuase an app to grow in size during execution and then crash. This is where Java is great with automatic garbage collection.
There is definatley less lines of code and more reuse in Cocoa over Carbon which will enbale you to write cleaner apps that work well faster. lastly, what one or two developers writing in Cocoa would be like a few or several developers in another developer environment. That is really key and you are seeing this when you go to places like version tracker.
On portability. If you develop a Cocoa App, you are definately writing just to OS X. In this case it makes little sense (unless you are leveraging existing code) to use Java with Cocoa. If you want more portable Java apps, you will use Swing (Doesn't come close to Aqua). I would only stick to ObjC (or C/C++) with Cocoa. If you were going to write a same app for both Cocoa/OS X and Windows, I am not sure how much code you could port/use from one env to the other and Cocoa is tied in with the Frameworks and ObjC is really only a GNU/OS X language. So, I would think you would have to write two seperate implementations for multiplatform development. (Correct me if I am wrong here).
So, bottom line, if you are writing NEW apps, use Cocoa. If you are porting an existing OS 9 apps, use Carbon. The time you save in development and focusing on your core problems will be great.
<strong> Much of Cocoa's AppKit is not reentrant (meaning that it's not safe to make calls to the same method within multiple threads at once), and as a result there is an awkward arrangement built into the application frameworks where only one thread draws into the view (the window, essentially), and this thread also contains the main event loop. This is why Cocoa windows stop rendering when you hold the mouse down on the scrollbar thumb (but only that window stops updating, not the whole app or the whole system). </strong><hr></blockquote>
Thank you.
I'm actually writing custom scrollers to get around this but I didn't know the root cause. You wouldn't happen to know the exact document/url that details this would you? You see I needed my views contents to update while I was scrolling... so I tried using an embedded timer. Now I'm just playing around with with some custom scrollbars which is fun cuz mine aren't quite as small as the apple one's.... yeah
<strong>The Carbon programmer has a tremendous amount of control over the nature and performance of her application, which implies a tremendous amount of responsibility. The Cocoa programmer has a lot of work done for her behind the scenes.
</strong><hr></blockquote>
Yes, yes...but the real question is: Is God a woman too?
Now you can drag the scrollbar around to your heart's content, and your view will continue to update.
As far as drawing from separate threads in Cocoa, the reality afaik is that you can freely draw into views from just about any thread whenever you like. The only caveat is that you must use NSView's -lockFocusIfCanDraw instead of -lockFocus before you start your drawing, and you need to arrange things so that the -drawRect method in your main thread either 1) does nothing and lets the secondary thread do all of the drawing or 2) otherwise cooperates through some kind of locking mechanism to avoid conflicts with the other drawing thread.
[ 05-31-2002: Message edited by: Josef K. ]
Um, that silly smiley face in the middle of the code is supposed to be a colon and a closing parenthesis. I don't know how to get rid of it. :hmmm:
[ 05-31-2002: Message edited by: Josef K. ]
Jesus...I'll get this (somewhat) right eventually...
Now you can drag the scrollbar around to your heart's content, and your view will continue to update.
<hr></blockquote>
Wow. Thanks. This thread is becoming more and more germain to my current hobby. I'll definately look into this code, though I may be keeping my custom scrollers. I'm also doing them as a scalable interface test. I find the default widgets, being bitmaps with maybe 2 variations a bit limiting. I run Os X at 1152x870 @ 100hz (on a 19" crt) for visibility and interference avoidance(really noisy power here). I find when I run at sizes 1280x1024 and above the widgets and general UI of many programs start to break down (see Netscape). The scrollers I'm working on will have a range of width/height based on the current screen resolution. Anyway thanks again.
[quote]<strong>If you're working too hard (writing a custom scrollbar class, for example), it's a good sign that you're doing something wrong. The idea that "the AppKit is non-reentrant" is, while true to some extent, also somewhat of a myth.</strong><hr></blockquote>
There are ways around, obviously. And I know from one of the Frameworks guys that Apple is working hard to make it fully reentrant.
[snip all kinds of good stuff]
I really need to get my hands dirty with this stuff.
[quote]<strong>Um, that silly smiley face in the middle of the code is supposed to be a colon and a closing parenthesis. I don't know how to get rid of it.</strong><hr></blockquote>
There's a "Disable smilies in this post" checkbox option on the posting and editing pages, under "Options."
So, bottom line, if you are writing NEW apps, use Cocoa. If you are porting an existing OS 9 apps, use Carbon. The time you save in development and focusing on your core problems will be great.
There's another really cool trick with Cocoa and Obj-C, it's that you can iterate thru versions of your code much faster than you typically can any place else.
So if you can afford to (we're talking ideal world here), do the first three re-writes, er uh *versions* of your app in Cocoa, and then, once you've got it right, if you absolutely have to, then port the sucker ...
... even if it means a complete re-write into something else, you'll at least now know the best way to architect the system, and you won't have to waste an incredible amount of time doing re-writes in a language not designed for that kind of thing.
There's another really cool trick with Cocoa and Obj-C, it's that you can iterate thru versions of your code much faster than you typically can any place else.
So if you can afford to (we're talking ideal world here), do the first three re-writes, er uh *versions* of your app in Cocoa, and then, once you've got it right, if you absolutely have to, then port the sucker ...
... even if it means a complete re-write into something else, you'll at least now know the best way to architect the system, and you won't have to waste an incredible amount of time doing re-writes in a language not designed for that kind of thing.</strong><hr></blockquote>
That's an idea. I also like using OmniGraffe's UML palettes to layout or spec the app or you could simple prototype using IB. Either, pretty good stuff........
Comments
In fact, the same features that make Cocoa so easy to develop in can make it really slow. The biggest variable by far is quality of implementation.
It's just so often when I read "Man! Can you imagine how much FASTER this will be when they write it for Cocoa??"
And I get real confused.
But - here's something.
If they're writing it for Cocoa - will they have to re-write everything?
I guess there's always the possibility of them tweaking old inefficient code, right?
Is using the Cocoa framework kind of like writing HTML in some dumbed down WYSIWYG app?
added: Also, Carbon seems to be given its poor repute thanks mainly to ports of older applications that don't use Carbon Events, among other things. Seems like the biggest Carbon anti-heroes (like the Finder) use the old method of WaitNextEvent and stuff like that, not to mention that they comile them differently and don't bother to dice them up as threads.
[ 05-30-2002: Message edited by: BuonRotto ]</p>
<strong>HIt's just so often when I read "Man! Can you imagine how much FASTER this will be when they write it for Cocoa??"</strong><hr></blockquote>That's because, to put it bluntly, those people are non-programmer morons who've jumped on the closest bandwagon to complain about something they don't understand.
[quote]<strong>If they're writing it for Cocoa - will they have to re-write everything?</strong><hr></blockquote>Not necessarily *everything* but, yes, certainly a vast majority of code. [quote]Originally posted by BuonRotto:
<strong>It is possible to wrap some Carbon coding into Cocoa objects I think.</strong><hr></blockquote>Correct. QuickTime for example is Carbon yet it can work just fine in Cocoa apps.
All in all, people just mistakenly think that Carbon is bad because they've seen so many bad Carbon ports. That's the fault of the programmers, not necessarily Carbon. Carbon code requires a bit more writing than Cocoa, but as Amorph said if you write the code using the correct *newer* models, then you can get a great app.
[ 05-30-2002: Message edited by: starfleetX ]</p>
Is carbon not as multi-threaded as cocoa?
<strong>Is carbon not as multi-threaded as cocoa?</strong><hr></blockquote>Well, I wouldn't say that. Carbon can be as threaded as any Cocoa app, with some small exceptions I can't recall, but you're just seeing another case where developers haven't completely moved over to the newer event model. QuickTime Player, for example, is a Carbon app and will keep playing movies while you hold the mouse down. Audion, another Carbon app, processes the addition of files to the playlist, <a href="http://brad.project-think.com/movies/audion-with-menus.mov"; target="_blank">constantly updating while you mouse down through the menus</a>.
[ 05-30-2002: Message edited by: starfleetX ]</p>
Snapz Pro X is an excellent example of what a Carbon app can be if the developer exploits its potential.
Finder has the additional problem of being a proof of concept for MetroWerks' PowerPlant class libraries, so as with Cocoa apps it will "magically" improve as MetroWerks improves their port of the PowerPlant classes.
Note that it is possible for a Carbon app to be better threaded than a Cocoa app. Much of Cocoa's AppKit is not reentrant (meaning that it's not safe to make calls to the same method within multiple threads at once), and as a result there is an awkward arrangement built into the application frameworks where only one thread draws into the view (the window, essentially), and this thread also contains the main event loop. This is why Cocoa windows stop rendering when you hold the mouse down on the scrollbar thumb (but only that window stops updating, not the whole app or the whole system). It's quite possible to make a Carbon app that doesn't exhibit that behavior.
Lastly, they key project which is awesome is the Apple Seed project which can help you run an app in a *clustered* environment. This means that a program like BLAST from Genetech can run on a farm of XServers utilizing not just dual processor systems but a farm of dual processors systems in a clustered environment. There is an sample of this called Pooch.
So, here are the four main areas where apps can be optimized to their max potential:
1. Implementation of code
2. AltiVec enhanced (utilize the G4). not all do this.
3. Multithread the app
4. Enble clustering (via Pooch/AppleSeed)
(This is like how SETI is run for example)
I like Cocoa a lot. It save me time doing the mundane stuff over and over by using the App or Foundation Kits but also other frameworks. Learning the APIs/Frameworks and the concept of Model View Controller and message passing in OO takes some getting your head wrapped around but once you are through it, its awesome (IMHO). I also like ObjC, its just like C. It has some danger points in that its loosly typed (id) but you can make it strongly typed if you want. Also, you have to watch out for garbage collection and releasing objects, and memory management which can cuase an app to grow in size during execution and then crash. This is where Java is great with automatic garbage collection.
There is definatley less lines of code and more reuse in Cocoa over Carbon which will enbale you to write cleaner apps that work well faster. lastly, what one or two developers writing in Cocoa would be like a few or several developers in another developer environment. That is really key and you are seeing this when you go to places like version tracker.
On portability. If you develop a Cocoa App, you are definately writing just to OS X. In this case it makes little sense (unless you are leveraging existing code) to use Java with Cocoa. If you want more portable Java apps, you will use Swing (Doesn't come close to Aqua). I would only stick to ObjC (or C/C++) with Cocoa. If you were going to write a same app for both Cocoa/OS X and Windows, I am not sure how much code you could port/use from one env to the other and Cocoa is tied in with the Frameworks and ObjC is really only a GNU/OS X language. So, I would think you would have to write two seperate implementations for multiplatform development. (Correct me if I am wrong here).
So, bottom line, if you are writing NEW apps, use Cocoa. If you are porting an existing OS 9 apps, use Carbon. The time you save in development and focusing on your core problems will be great.
[ 05-31-2002: Message edited by: eat@me ]</p>
<strong> Much of Cocoa's AppKit is not reentrant (meaning that it's not safe to make calls to the same method within multiple threads at once), and as a result there is an awkward arrangement built into the application frameworks where only one thread draws into the view (the window, essentially), and this thread also contains the main event loop. This is why Cocoa windows stop rendering when you hold the mouse down on the scrollbar thumb (but only that window stops updating, not the whole app or the whole system). </strong><hr></blockquote>
Thank you.
I'm actually writing custom scrollers to get around this but I didn't know the root cause. You wouldn't happen to know the exact document/url that details this would you? You see I needed my views contents to update while I was scrolling... so I tried using an embedded timer. Now I'm just playing around with with some custom scrollbars which is fun cuz mine aren't quite as small as the apple one's.... yeah
<strong>The Carbon programmer has a tremendous amount of control over the nature and performance of her application, which implies a tremendous amount of responsibility. The Cocoa programmer has a lot of work done for her behind the scenes.
</strong><hr></blockquote>
Yes, yes...but the real question is: Is God a woman too?
target:self
selector:@selector(drawStuff
userInfo:nil repeats:YES];
[[NSRunLoop currentRunLoop] addTimer:timer
forMode:NSDefaultRunLoopMode];
[[NSRunLoop currentRunLoop] addTimer:timer
forMode:NSEventTrackingRunLoopMode];</pre><hr></blockquote>
Now you can drag the scrollbar around to your heart's content, and your view will continue to update.
As far as drawing from separate threads in Cocoa, the reality afaik is that you can freely draw into views from just about any thread whenever you like. The only caveat is that you must use NSView's -lockFocusIfCanDraw instead of -lockFocus before you start your drawing, and you need to arrange things so that the -drawRect method in your main thread either 1) does nothing and lets the secondary thread do all of the drawing or 2) otherwise cooperates through some kind of locking mechanism to avoid conflicts with the other drawing thread.
[ 05-31-2002: Message edited by: Josef K. ]
Um, that silly smiley face in the middle of the code is supposed to be a colon and a closing parenthesis. I don't know how to get rid of it. :hmmm:
[ 05-31-2002: Message edited by: Josef K. ]
Jesus...I'll get this (somewhat) right eventually...
[ 05-31-2002: Message edited by: Josef K. ]
[edit by Amorph: Disabled smilies.]
[ 05-31-2002: Message edited by: Amorph ]</p>
Now you can drag the scrollbar around to your heart's content, and your view will continue to update.
<hr></blockquote>
Wow. Thanks. This thread is becoming more and more germain to my current hobby. I'll definately look into this code, though I may be keeping my custom scrollers. I'm also doing them as a scalable interface test. I find the default widgets, being bitmaps with maybe 2 variations a bit limiting. I run Os X at 1152x870 @ 100hz (on a 19" crt) for visibility and interference avoidance(really noisy power here). I find when I run at sizes 1280x1024 and above the widgets and general UI of many programs start to break down (see Netscape). The scrollers I'm working on will have a range of width/height based on the current screen resolution. Anyway thanks again.
There are ways around, obviously.
[snip all kinds of good stuff]
I really need to get my hands dirty with this stuff.
[quote]<strong>Um, that silly smiley face in the middle of the code is supposed to be a colon and a closing parenthesis. I don't know how to get rid of it.</strong><hr></blockquote>
There's a "Disable smilies in this post" checkbox option on the posting and editing pages, under "Options."
<strong>
So, bottom line, if you are writing NEW apps, use Cocoa. If you are porting an existing OS 9 apps, use Carbon. The time you save in development and focusing on your core problems will be great.
[ 05-31-2002: Message edited by: eat@me ]</strong><hr></blockquote>
There's another really cool trick with Cocoa and Obj-C, it's that you can iterate thru versions of your code much faster than you typically can any place else.
So if you can afford to (we're talking ideal world here), do the first three re-writes, er uh *versions* of your app in Cocoa, and then, once you've got it right, if you absolutely have to, then port the sucker ...
... even if it means a complete re-write into something else, you'll at least now know the best way to architect the system, and you won't have to waste an incredible amount of time doing re-writes in a language not designed for that kind of thing.
<strong>
There's another really cool trick with Cocoa and Obj-C, it's that you can iterate thru versions of your code much faster than you typically can any place else.
So if you can afford to (we're talking ideal world here), do the first three re-writes, er uh *versions* of your app in Cocoa, and then, once you've got it right, if you absolutely have to, then port the sucker ...
... even if it means a complete re-write into something else, you'll at least now know the best way to architect the system, and you won't have to waste an incredible amount of time doing re-writes in a language not designed for that kind of thing.</strong><hr></blockquote>
That's an idea. I also like using OmniGraffe's UML palettes to layout or spec the app or you could simple prototype using IB. Either, pretty good stuff........