Comments on: The Cocoa-Carbon Advantage http://www.red-sweater.com/blog/181/the-cocoa-carbon-advantage Mac & Technology Writings by Daniel Jalkut Wed, 17 Mar 2010 22:33:24 +0000 http://wordpress.org/?v=2.9 hourly 1 By: Daniel Jalkut http://www.red-sweater.com/blog/181/the-cocoa-carbon-advantage/comment-page-2#comment-16501 Daniel Jalkut Wed, 27 Sep 2006 17:34:48 +0000 http://www.red-sweater.com/blog/181/the-cocoa-carbon-advantage#comment-16501 Agree with Eric, especially considering that there are behaviors that are better in Carbon than in Cocoa. So it goes both ways. And if Apple didn't want to support Carbon, they would have made that a lot clearer than just a few UI glitches. Remember Classic? Agree with Eric, especially considering that there are behaviors that are better in Carbon than in Cocoa. So it goes both ways. And if Apple didn’t want to support Carbon, they would have made that a lot clearer than just a few UI glitches. Remember Classic?

]]> By: Eric Albert http://www.red-sweater.com/blog/181/the-cocoa-carbon-advantage/comment-page-2#comment-16499 Eric Albert Wed, 27 Sep 2006 17:30:43 +0000 http://www.red-sweater.com/blog/181/the-cocoa-carbon-advantage#comment-16499 I'd suggest not ascribing to politics what can more easily be explained by there being more important things to fix. I’d suggest not ascribing to politics what can more easily be explained by there being more important things to fix.

]]> By: Neo http://www.red-sweater.com/blog/181/the-cocoa-carbon-advantage/comment-page-2#comment-16428 Neo Wed, 27 Sep 2006 04:38:12 +0000 http://www.red-sweater.com/blog/181/the-cocoa-carbon-advantage#comment-16428 Sadly this demonstrates why one must prefer one part of OS X over the other: Carbon is out of sync from Cocoa (and vice versa). The icon returned should be exactly the same, but NSWorkspace is apparently doing some voo-doo to get the *most current* preferred icons. ThIs implies that NSWorkspace is designed to go and get a different icon than what is actually defined in the bowels of OS X. This preferential treatment of Cocoa is what really irks (some) old-school Carbon developers. Apple engineers are intentionally making Carbon appear antiquated or "broken" compared to Cocoa, even though Carbon is technically capable of regurgitating the correct, modern, icon. Another area where Carbon is deliberately hindered vs. Cocoa is in the "grow thumb" in Carbon windows, which appears as a solid-white background square instead of transparent as in Cocoa-derived windows. Carbon can make the grow thumb appear identical to Cocoa windows, it is simply not the default appearance for no technical reason whatsoever (just political ones, methinks, but what do I know). Sadly this demonstrates why one must prefer one part of OS X over the other: Carbon is out of sync from Cocoa (and vice versa).

The icon returned should be exactly the same, but NSWorkspace is apparently doing some voo-doo to get the *most current* preferred icons. ThIs implies that NSWorkspace is designed to go and get a different icon than what is actually defined in the bowels of OS X.

This preferential treatment of Cocoa is what really irks (some) old-school Carbon developers. Apple engineers are intentionally making Carbon appear antiquated or “broken” compared to Cocoa, even though Carbon is technically capable of regurgitating the correct, modern, icon.

Another area where Carbon is deliberately hindered vs. Cocoa is in the “grow thumb” in Carbon windows, which appears as a solid-white background square instead of transparent as in Cocoa-derived windows. Carbon can make the grow thumb appear identical to Cocoa windows, it is simply not the default appearance for no technical reason whatsoever (just political ones, methinks, but what do I know).

]]> By: Nathan Herring http://www.red-sweater.com/blog/181/the-cocoa-carbon-advantage/comment-page-1#comment-15396 Nathan Herring Tue, 19 Sep 2006 18:12:03 +0000 http://www.red-sweater.com/blog/181/the-cocoa-carbon-advantage#comment-15396 Alas, there are two issues with using Cocoa intermixed with Carbon that have a deleterious effect on performance. (1) Loading of extra libraries at launch (not a terribly big deal) (2) You cannot unload Cocoa-based bundles as the Objective-C runtime cannot guarantee that all objects lifetimes are terminated. That said, the post and the comments are spot on. Alas, there are two issues with using Cocoa intermixed with Carbon that have a deleterious effect on performance.
(1) Loading of extra libraries at launch (not a terribly big deal)
(2) You cannot unload Cocoa-based bundles as the Objective-C runtime cannot guarantee that all objects lifetimes are terminated.
That said, the post and the comments are spot on.

]]> By: Louis http://www.red-sweater.com/blog/181/the-cocoa-carbon-advantage/comment-page-1#comment-14457 Louis Tue, 12 Sep 2006 12:35:38 +0000 http://www.red-sweater.com/blog/181/the-cocoa-carbon-advantage#comment-14457 Cocoa is excellent for interfaces, but sadly it lacks a lot of things that can be found in carbon. I prefer cocoa, but I'm not afraid to use carbon where cocoa falls short. Cocoa is excellent for interfaces, but sadly it lacks a lot of things that can be found in carbon. I prefer cocoa, but I’m not afraid to use carbon where cocoa falls short.

]]> By: Chris Thomas http://www.red-sweater.com/blog/181/the-cocoa-carbon-advantage/comment-page-1#comment-14328 Chris Thomas Mon, 11 Sep 2006 03:09:32 +0000 http://www.red-sweater.com/blog/181/the-cocoa-carbon-advantage#comment-14328 Daniel: I, too, have Carbon icon code in some of my Cocoa apps. I think there is a point being overlooked in the discussion of NSWorkspace vs GetIconRef. IconServices was designed (partly) to minimize memory usage: for each icon on the system, there should be one and only one instance of pixel data/cache in memory, and all applications should render the icon from that same instance data via PlotIconRef. So, try this: Call [[NSWorkspace sharedWorkspace] iconForFileType:NSFileTypeForHFSTypeCode('prof')]; three times in the same function, logging the result with NSLog("%@") after each. Call GetIconRef and printf("%08lX") the resulting iconRef three times. Notice the difference? (Aside from the much richer description returned by NSLog...) This is a much bigger problem with file-specific icons retrieved through NSWorkspace, where you might invoke iconForFile: way too often if you aren't aware of the problem. You can cache the generic icon (still once per app rather than once per system, though). File-specific icons, not so much. Rosyna: What does Cocoa have to do with Aperture's slowness, especially in the 1.0? Unless they ported it to Carbon in 1.1, I find it unlikely that you can pin that on Cocoa. But if you can really trace Aperture's performance issues to indiscriminate use of Cocoa rather than Carbon, I and others would certainly like to see the analysis. Daniel: I, too, have Carbon icon code in some of my Cocoa apps. I think there is a point being overlooked in the discussion of NSWorkspace vs GetIconRef. IconServices was designed (partly) to minimize memory usage: for each icon on the system, there should be one and only one instance of pixel data/cache in memory, and all applications should render the icon from that same instance data via PlotIconRef.

So, try this:

Call [[NSWorkspace sharedWorkspace] iconForFileType:NSFileTypeForHFSTypeCode(‘prof’)]; three times in the same function, logging the result with NSLog(“%@”) after each.

Call GetIconRef and printf(“%08lX”) the resulting iconRef three times.

Notice the difference? (Aside from the much richer description returned by NSLog…)

This is a much bigger problem with file-specific icons retrieved through NSWorkspace, where you might invoke iconForFile: way too often if you aren’t aware of the problem. You can cache the generic icon (still once per app rather than once per system, though). File-specific icons, not so much.

Rosyna: What does Cocoa have to do with Aperture’s slowness, especially in the 1.0? Unless they ported it to Carbon in 1.1, I find it unlikely that you can pin that on Cocoa. But if you can really trace Aperture’s performance issues to indiscriminate use of Cocoa rather than Carbon, I and others would certainly like to see the analysis.

]]> By: frank riffold http://www.red-sweater.com/blog/181/the-cocoa-carbon-advantage/comment-page-1#comment-14281 frank riffold Sun, 10 Sep 2006 21:42:40 +0000 http://www.red-sweater.com/blog/181/the-cocoa-carbon-advantage#comment-14281 In some (non-gui) apps the Carbon framework can come in handy for specific tasks ( cf. How to detect string encoding? on http://www.macosxguru.net/article.php?story=20030808081801868 ). In some (non-gui) apps the Carbon framework can come in handy for specific tasks ( cf. How to detect string encoding? on http://www.macosxguru.net/article.php?story=20030808081801868 ).

]]> By: Noodlings » System Icon Viewer http://www.red-sweater.com/blog/181/the-cocoa-carbon-advantage/comment-page-1#comment-14254 Noodlings » System Icon Viewer Sun, 10 Sep 2006 16:44:52 +0000 http://www.red-sweater.com/blog/181/the-cocoa-carbon-advantage#comment-14254 [...] When I saw this post, I mentioned to Daniel Jalkut that I had done the same thing that he did (which was to create an NSImage category to access Carbon’s Icon Manager’s icons). After his obligatory insistence that I start a blog, I sent him a little program I had thrown together to preview the icons. [...] [...] When I saw this post, I mentioned to Daniel Jalkut that I had done the same thing that he did (which was to create an NSImage category to access Carbon’s Icon Manager’s icons). After his obligatory insistence that I start a blog, I sent him a little program I had thrown together to preview the icons. [...]

]]> By: Rosyna http://www.red-sweater.com/blog/181/the-cocoa-carbon-advantage/comment-page-1#comment-14191 Rosyna Sun, 10 Sep 2006 08:17:16 +0000 http://www.red-sweater.com/blog/181/the-cocoa-carbon-advantage#comment-14191 Scott Stevenson, and notice how slow Aperture is, especially the 1.0? The NSWorkspace method is getting the icon for the file that has a create code of '????' (ie, any) and the file type you give it. Your GetIconRef is getting the icons with a creator of kSystemIconsCreator ('macs'), which is a very, very specific domain/application. If you passed '????' to the GetIconRef() function, you'd get the same result. Although you really should use GetIconRefFromTypeInfo(), which is *exactly* what NSWorkspace's iconForFileType: is doing. However, try drawing the image returned from iconForFileType: in any size than 32x32. Scott Stevenson, and notice how slow Aperture is, especially the 1.0?

The NSWorkspace method is getting the icon for the file that has a create code of ‘????’ (ie, any) and the file type you give it. Your GetIconRef is getting the icons with a creator of kSystemIconsCreator (‘macs’), which is a very, very specific domain/application. If you passed ‘????’ to the GetIconRef() function, you’d get the same result. Although you really should use GetIconRefFromTypeInfo(), which is *exactly* what NSWorkspace’s iconForFileType: is doing. However, try drawing the image returned from iconForFileType: in any size than 32×32.

]]> By: Helge http://www.red-sweater.com/blog/181/the-cocoa-carbon-advantage/comment-page-1#comment-14184 Helge Sun, 10 Sep 2006 07:22:26 +0000 http://www.red-sweater.com/blog/181/the-cocoa-carbon-advantage#comment-14184 To those people who don't believe Carbon applications can look and feel like Cocoa applications: Check out the Nano framework, which is "pure" Carbon: http://www.refnum.com/products/nano/ Take a look at the example applications. I'm sure almost every Mac user would assume they were Cocoa. To those people who don’t believe Carbon applications can look and feel like Cocoa applications: Check out the Nano framework, which is “pure” Carbon:

http://www.refnum.com/products/nano/

Take a look at the example applications. I’m sure almost every Mac user would assume they were Cocoa.

]]>