Sidebar Sidebar
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

iTunes 10.5 - Cocoa or Carbon?

ErikGrim said:
Complete without elastics and an insanely low framerate. I can literally see the steps in the fade out animation when I stop scrolling. (New SSD iMac BTW in case you think my system is at fault).
Click to expand...

Cocoa isn't magically going to fix framerate issues. Much of Cocoa is built on top of Foundation (Carbon) APIs anyway, so it ends up calling the same code.
 
I hope the guy behind Vox hurries up and releases it with a library.
iTunes is bloat, and the name is misleading, not everyone cares for ipod, ipad, iphone, aTV, itms, and all that other junk inflating an application JUST to play music.
 
slb said:
Cocoa isn't magically going to fix framerate issues. Much of Cocoa is built on top of Foundation (Carbon) APIs anyway, so it ends up calling the same code.
Click to expand...

It is not using the native list view, which causes the poor performance. So yes, using the native view would give you "magically" better performance. If you've used Twitter on the DPs you'll remember when they switched to the native scroll list view.
 
So iTunes is finally a cocoa app or has Apple removed the 32-bit carbon limitation?
 
Last edited:
Who cares, right now im using iTunes on a 2010 MacMini and performance is excellent. I don't see how it could perform any better.
 
Anyone care to post of screen shot of full screen?

Is there anything unique in full screen as far as how the app behaves?
 
ErikGrim said:
It is not using the native list view, which causes the poor performance.
Click to expand...

A Carbon table view isn't going to cause any noticeably poor performance. iTunes' bottleneck while scrolling is most likely in its database access. A Cocoa application would require the same manual pre-fetching performance work that a Carbon application would, so switching to Cocoa wouldn't suddenly make scrolling faster. If you're talking about actually drawing to the screen, both Cocoa and Carbon are going through Quartz.

So yes, using the native view would give you "magically" better performance. If you've used Twitter on the DPs you'll remember when they switched to the native scroll list view.
Click to expand...

Twitter has always been a Cocoa application.
 
I'd reckon the reason iTunes 10.5 says it needs Carbon is that the 32-bit versions need it, not necessarily the x64 version. If you built this app as a 64-bit only app, it might report it's need for Carbon differently.
 
Idk if anyone mentioned it but it only runs in 64-bit on Lion, not SL or below...

Just throwing that out there. *Hides*
 
slb said:
A Carbon table view isn't going to cause any noticeably poor performance. iTunes' bottleneck while scrolling is most likely in its database access. A Cocoa application would require the same manual pre-fetching performance work that a Carbon application would, so switching to Cocoa wouldn't suddenly make scrolling faster. If you're talking about actually drawing to the screen, both Cocoa and Carbon are going through Quartz.



Twitter has always been a Cocoa application.
Click to expand...
That's not the point. What iTunes and Twitter have (or had) in common is that they both roll their own table view.

It's easily identifiable by the jerky scrolling and the fact that there is no elasticity (i.e. no bounce at the end).
 
You must log in or register to reply here.
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.
Top Bottom
Back