SHOCKER! iTunes is made with RealBasic?
NOT a **ConF1Rm3D** BUT VERY INTERESTING
About a month ago, I had an issue with RealBasic v2006 that I contacted RealSoftware about in their forums to try to resolve, or find a workaround too. Basically in RealBasic, if you create a canvas control and mousedown on it, it will spike your CPU useage to 100% and make everything really 'bad' until you mouseup - even if there is no code to execute. Not a 'bug' as such but a 'design flaw' as confirmed by a developer in the RB forum - Now because RB2006 is made with RB2006, the main interface in RB2006 IS a Canvas control so....
Anyhow, I've been hearing about all these issues with iTunes 7 being choppy, so I was reluctant to download it, but I thought 'what the hell' i'll give it a try. For sure, playing videoes in iTunes 7 has 'issues'!
So anyway, as the RB issue is fresh in my mind, i had this thought. I pulled up taskmanager in Windows to see whether iTunes is maxing out my CPU when playing videos and sure enough it IS - which explains the choppyness. BUT
Mousedown on a blank part of the iTunes interface (in the store homepage, this is the bluey/grey bit) and SHOCK!!! my CPU spikes to 100% - even though probably there is no reason for this to happen UNLESS the iTunes interface is a CANVAS CONTROL from RealBasic!!!
Both Applications are displaying an identical 'design flaw' - which is easily explained if iTunes 7 is compiled with RealBasic2006.
[sarcasm] I know I cant do the math to 'prove' this theory - so my idea is basically worthless
[/sarcasm]
For those who dont know what realBasic is - its a Rapid Application Development BASIC Programming Language thats best feature is that it is Cross Platform - exactly the kind of tool you'd want to make something like iTunes - And its VERY GOOD, apart from a few minor issues
[edit] Also the problem with iTunes 7 being so choppy is probably down to the fact, that if you load up the iTunes Store and leave it alone (only while connected to the internet) - and have taskmanager open, you can see that all on its own it is periodically spiking the CPU every couple of seconds or so.
About a month ago, I had an issue with RealBasic v2006 that I contacted RealSoftware about in their forums to try to resolve, or find a workaround too. Basically in RealBasic, if you create a canvas control and mousedown on it, it will spike your CPU useage to 100% and make everything really 'bad' until you mouseup - even if there is no code to execute. Not a 'bug' as such but a 'design flaw' as confirmed by a developer in the RB forum - Now because RB2006 is made with RB2006, the main interface in RB2006 IS a Canvas control so....
Anyhow, I've been hearing about all these issues with iTunes 7 being choppy, so I was reluctant to download it, but I thought 'what the hell' i'll give it a try. For sure, playing videoes in iTunes 7 has 'issues'!
So anyway, as the RB issue is fresh in my mind, i had this thought. I pulled up taskmanager in Windows to see whether iTunes is maxing out my CPU when playing videos and sure enough it IS - which explains the choppyness. BUT
Mousedown on a blank part of the iTunes interface (in the store homepage, this is the bluey/grey bit) and SHOCK!!! my CPU spikes to 100% - even though probably there is no reason for this to happen UNLESS the iTunes interface is a CANVAS CONTROL from RealBasic!!!
Both Applications are displaying an identical 'design flaw' - which is easily explained if iTunes 7 is compiled with RealBasic2006.
[sarcasm] I know I cant do the math to 'prove' this theory - so my idea is basically worthless
[/sarcasm]For those who dont know what realBasic is - its a Rapid Application Development BASIC Programming Language thats best feature is that it is Cross Platform - exactly the kind of tool you'd want to make something like iTunes - And its VERY GOOD, apart from a few minor issues
[edit] Also the problem with iTunes 7 being so choppy is probably down to the fact, that if you load up the iTunes Store and leave it alone (only while connected to the internet) - and have taskmanager open, you can see that all on its own it is periodically spiking the CPU every couple of seconds or so.
Comments
The design flaw you're describing is actually fairly common among older applications; if iTunes were to be revamped to take more advantage of Quartz paradigms, it wouldn't have to be this way.
iTunes is written in C++, with some Carbon, some CoreFoundation (and CF-Lite) and some QuickTime. It is compiled with Xcode on Mac OS, and with Visual C++ on Windows.
The design flaw you're describing is actually fairly common among older applications; if iTunes were to be revamped to take more advantage of Quartz paradigms, it wouldn't have to be this way.
well thats what I would have thought, but now Im not so sure. Do you have 'proof' of how iTunes is made to make that point?
I havn't got/seen any other applications where clicking on an essentially blank area of the interface would cause a CPU spike of 100% until the mouse was released.
Thats is a very odd thing indeed, and specific to applications compiled in RealBasic using a canvas control. Infact the whole iTunes experience on windows - generally how slow it is - is Screaming 'Made with RealBasic' to me.
Now, Im quite sure Quicktime and other Frameworks are involved, aswell as specific C++ bits compiled in xcode for speed etc- because it's easy to get hooks into these from RealBasic to improve functionality. But i do think that it is 'possible' that the UI and application are made with realbasic, because what is wrong with iTunes 7 at the moment - is exactly what you would expect when compiling a media-rich interface using realbasic.
well thats what I would have thought, but now Im not so sure. Do you have 'proof' of how iTunes is made to make that point?
Yeah, all you really have to do is look through the binary's strings. Plus, consider its history of SoundJam MP. iTunes has never been rewritten since.
I havn't got/seen any other applications where clicking on an essentially blank area of the interface would cause a CPU spike of 100% until the mouse was released.
Look no further than Firefox.
Yeah, all you really have to do is look through the binary's strings. Plus, consider its history of SoundJam MP. iTunes has never been rewritten since.
yes but do you know that it hasn't been rewritten or is that an assumption. Infact, you could re-write the whole of iTunes interface in RealBasic in less than a week. Thats why its called a RAD tool.
There are some very strange behaviours in iTunes 7 that as far as I can remember did not exist in previous versions. For instance - when the visualizer is running (not full screen) then trying to access any of the menu's will kill the FPS of the visualizer to 0.25 FPS, which is pretty odd if this code is a development of existing code, but would be almost guaranteed to happen if the UI had recently been ported to RB, because this is exactly what you would expect RB apps do.
The fact is, that as good as RealBasic is for many things, creating a media rich UI in realbasic is not one of its strengths. And iTunes 7 is certainly a UI/responsiveness dog compared to previous versions.
Have you looked at the binary of iT 7? I wouldn't know what I was looking for, but if you have, and you can identify the compiler used is not RB, then I'll happily accept I was wrong, and just put it down to being a coincidence between the two apps.
Look no further than Firefox.
not really the same problem. I have tried virtually every app I own including Firefox, to see if this behaviour is common, and certainly my Firefox doesn't do that. But my point is, its not the same problem, because that bug, is caused by the user doing 'something that would require execution of code', clicking a mouse on 'nothing' shouldn't execute a continuous loop.
yes but do you know that it hasn't been rewritten or is that an assumption.
It's common sense.
Infact, you could re-write the whole of iTunes interface in RealBasic in less than a week. Thats why its called a RAD tool.
The interface? Sure. The workings? No.
And what reason would Apple have to do such a rewrite from a decent framework to an inferior one?
Have you looked at the binary of iT 7?
Yes. It's very, very similar to that of iTunes 6.
It's common sense.
The interface? Sure. The workings? No.
And what reason would Apple have to do such a rewrite from a decent framework to an inferior one?
Yes. It's very, very similar to that of iTunes 6.
Common sense isn't proof. I agree its common sense. I wouldn't have thought Apple would use RB to make iTunes unless there are some very specific common problems between both applications. Which there ARE!
Im arguing that the interface IS RB. Im quite sure that most of the guts of the application isn't RB and are infact originated using the tools you describe - but as extensions and plug-ins to an 'Interface' that was created in RB
And I think the reason it is *possible* apple would do it, is because RB is a RAD tool, and it would cut the development time considerably than coding in C++ - remember - Microsoft used RB to create the Macintosh version of IE. Likely one of the reasons it wasn't much good.
Im arguing that the interface IS RB.
Then you should be the one to prove it.
Microsoft used RB to create the Macintosh version of IE.
Wrong, they used RB for UI prototyping. The shipping Mac apps from Microsoft have no REALbasic code in them at all.
Obviously you cant 'disprove' it either other than using appeals to common sense and what you'd like to believe Apple uses to write its apps.
I'd like to believe Apple doesn't use RealBasic to create an app like itunes, because it isn't common sense to do so - Unless you want to quickly knock up a graphically rich UI that is slow, unresponsive and flakey. But if the boot fits...
Obviously you cant 'disprove' it either other than using appeals to common sense and what you'd like to believe Apple uses to write its apps.
I have already stated that the binary looks very close in design to that of iTunes 6. For some reason, you seem to conveniently ignore that this effectively disproves your theory.
For instance, in iTunes, regardless of version, why is window resizing such a dog? You can easily find much graphically richer webpages that will resize instantly in your browser. Yet iTunes has virtually nothing to do, yet makes a pigs ear out of it.
If I was to recreate an iTunes interface with RB, this kind of sluggishness is EXACTLY what i would expect to happen if I created the main window using a canvas control.
Same with using the scroll wheel to move up and down the library. Create a similar interface in RB and sluggishness is exactly what you will get.
Surely something created in C++ and xcode wouldn't be that bad unless you were a *really* bad programmer?
For instance, in iTunes, regardless of version, why is window resizing such a dog?
This results from several aspects, but mainly, it would be a lot faster if iTunes's UI were Cocoa.
Instead, iTunes's UI is done through various resources. All the gradients and such are little graphics that have to be resized to fit as you resize the window. Since resizing is live, they actually have to be resized many times a second. You can resize a lot faster by holding cmd while resizing, which will temporarily turn off live-resizing. In iTunes 4.x and older, this was many times more slower as it used brushed metal instead of gradients, which meant a significantly more complex texture to work with.
Another reason is the table view. Its contents are apparently not buffered (beyond the Quartz buffering, which only applies to what's visible), so they are regenerated during resizing as well.
This results from several aspects, but mainly, it would be a lot faster if iTunes's UI were Cocoa.
Instead, iTunes's UI is done through various resources. All the gradients and such are little graphics that have to be resized to fit as you resize the window. Since resizing is live, they actually have to be resized many times a second. You can resize a lot faster by holding cmd while resizing, which will temporarily turn off live-resizing. In iTunes 4.x and older, this was many times more slower as it used brushed metal instead of gradients, which meant a significantly more complex texture to work with.
Another reason is the table view. Its contents are apparently not buffered (beyond the Quartz buffering, which only applies to what's visible), so they are regenerated during resizing as well.
so what in your opinion have apple used to create iTunes? and why is it so bad?
For your argument above about resizing, do you really think that a few calculations on scaling graphics could need that much CPU as to make the application such a dog? And the graphics dont actually change size - and in tests i have done using RB, you can scale bitmaps, many bitmaps, horizontally really quickly to keep up with your window resizing - on their own the calculations to do this wouldn't suck up that much CPU. Are you suggesting they are vector gradients? I'd doubt it.
Consider this website
http://www.overclockers.co.uk/
a similar sort of layout to iTunes, kind of the same type of calculations being done when you resize the browser window, yet its instant.
The programmers of iTunes must be really shot away if they cant come up with better code than we have now.
so what in your opinion have apple used to create iTunes? and why is it so bad?
I already stated as much. And it's not "bad"; it's merely an aging architecture. They would probably replace a lot of the code, if they could, but that would render it incompatible with Windows, which doesn't have a composited UI (Vista will, but not even in all editions, so it isn't something Apple will be able to rely on for many years to come).
They try to keep the Mac OS and Windows codebases as similar as possible, and that means compromises.
Are you suggesting they are vector gradients? I'd doubt it.
No, it's all pixel-based.
The programmers of iTunes must be really shot away if they cant come up with better code than we have now.
Yeah, I invite you to pull off something similar. Good luck.
Yeah, I invite you to pull off something similar. Good luck.
funny that, but in the interlude, I just knocked up a quick interface in RB using my method of resizing bitmaps (i chose to scale 20 of them as the window resized) and found it to be an order of magnitude quicker than iTunes. So maybe the question should be
Why aren't Apple using RealBasic for their UI?
No wonder you're having problems with comprehending the situation...
MarcUK, mouse-down-on-anywhere-causing-freeze was also a symptom of every app on MacOS 9, MacOS 8, System 7, System 6... by your logic, OMGWTFBBQ!1!!1!1 RealBasic has been used to create the Mac *all along*!
Er, no.
There's no RB in iTunes.
And what is fake about a compiled realbasic app?
When did this become an issue for windows? Perhaps you could tell me what the compiler is / or what the kind of dubious coding is - that generates a mouse-down-on-anywhere-freeze in an application? Because someone needs to tell Apple Not to use it.
And also, is it not a bit odd that in iTunes7 you will get this unwanted behaviour on the blueygrey background, but not if you mousedown on something outside this area? Which again is something specific to Realbasic if you've ever had the opportunity to use it.
fine.
And what is fake about a compiled realbasic app?
Because, uh, you neglected to give your app any functionality? iTunes has lots of complexity, from encoding and decoding to various forms of visualization to managing tens of thousands of database entries.
RBValArchive
RBMailDB
RBFilemakerAttachment
RBFilemakerAttachment
RBMailDB
RBValArchive
RBWhichMailboxes
RBWhichMailboxes
RBWhichMailboxes
RBMailClient
RBMailClient
&RBMailClient_MouseEnter%%o<CCEmailApp>
%RBMailClient_MouseExit%%o<CCEmailApp>
RBMailClient_Open%%o<CCEmailApp>
"RBMailClient_Action%%o<CCEmailApp>
*RBWhichMailboxes_MouseExit%%o<CCMailboxes>
+RBWhichMailboxes_MouseEnter%%o<CCMailboxes>
%RBWhichMailboxes_Open%%o<CCMailboxes>
RBMailDB_MouseExit%%o<CCExport>
RBMailDB_Open%%o<CCExport>
RBMailDB_MouseEnter%%o<CCExport>
#RBValArchive_MouseExit%%o<CCExport>
RBValArchive_Open%%o<CCExport>
$RBValArchive_MouseEnter%%o<CCExport>
,RBFilemakerAttachment_MouseExit%%o<CCExport>
'RBFilemakerAttachment_Open%%o<CCExport>
-RBFilemakerAttachment_MouseEnter%%o<CCExport>
Constructor%%o<RBMailDB>i4
Then I did the same for iTunes 7. Here is the *complete* result:
kDRBurnStatusChangedNotification
kDRBlockSizeKey
kDRBlockTypeKey
kDRBurnRequestedSpeedKey
kDRBurnVerifyDiscKey
kDRBurnAppendableKey
kDRBurnCompletionActionKey
kDRBurnCompletionActionMount
kDRBurnTestingKey
DRBurnCopyStatus
DRBurnGetProperties
DRBurnCreate
DRBurnAbort
DRBurnSetProperties
DRBurnWriteLayout
com_apple_driver_iPodRBCNub
4RB>
$]3cM8RBh
%`RBp
RB0
XRBM
P@RB
vPGRB
E5RB
IY,<7'RB
IY,<7'RB
kHRBT
Ja[BnRB
o2RB
pN2^LlRB|
RBoo
5RBV%VQH
?ulYRBv
(RB.
RB^L9
Can we put a bullet through this one now?
The behaviour you're seeing is because of a brain-dead wait loop. MacOS Toolbox had it, Classic has it, Carbon inherited it (and it still pops up sometimes), and just plain lazy programming will recreate it. It's nothing unique to RealBasic.