is trouble the currency of progress?

Apple sacrifices compatibility in favor of progress. our plug-ins pay the price. after chromakey, all plug-ins that use memory appear to be in danger of being paved over by the road to Intel. 'mix/blend movies' and 'multiple movies' appear to have become unstable with recent system releases.

as many of our customers know, the road to Intel compatibility is not half as smooth as some people (and Apple in particular) would have you to believe. in order to get OSX running on Intel and PowerPC simultaneously (a tremendous feat, and one that Apple deserves a lot of credit for), Apple had to sacrifice something. when Apple made the switch to OSX a few years ago, they devised a technology they called 'Carbon' that enabled people to harness the power of the new OS while remaining compatible with older (OS 8 and OS 9-based) applications. iMovie was one of those applications that originated in OS9 and acquired Carbon technology for OSX. the plug-in architecture for iMovie is still Carbon-based.

pushing new technologies, Apple forged ahead, and with each new OS release introduced new and enhanced features. until a few years ago, all applications relied on Apple's 'QuickDraw' technology to draw anything. to manage video and audio stream, Apple also developed the world-class QuickTime technology. then, a new drawing technology was introduced: 'Quartz'. it is an awesome technology, and very advanced. Quartz offers so many advantages that Apple has shifted QuickTime from QuickDraw as underlying drawing technology to Quartz. this is of course understandable, as it makes QuickTime a better product. if it weren't for a small snag: memory management.

you see, with OSX Apple introduced yet another new technology: Cocoa (actually, Cocoa was only new to Apple -- it has been around NeXT for quite a while). Cocoa is likewise an impressive technology that sports a feature that is as awesome as it is dangerous: automatic memory management (or better: 'garbage collection' as the compiler-savvy people call it). Cocoa can detect if a program isn't using a particular block of memory any more, and free it for other purposes.
this is great (especially for people programming in C, since most C programmers wouldn't know clean code if it backed over their head in a truck) as long as the application is programmed so that all memory is allocated exclusively using Cocoa technology.

iMovie in it's newer incarnations (definitely iMovie 5, 6) are Cocoa-based. yet, since iMovie demands that all plug-ins use Carbon-based code, the plug-ins rely on old-style memory management. many times this is no problem. most of our plug-ins receive a chunk of memory from iMovie, fiddle with it, and hand it back. these plug-ins have remained rock solid.
others have fared not as good. memory-intensive plug-ins (our chromakey line of plug-ins) were the first to hit this problem. what happens is this: the plug-in manages a lot of memory in addition to that handed to it by iMovie. this memory must be allocated, and the plug-in utilizes Carbon's (not Cocoa's) memory allocation routines. as long as the code does not leave plug-in, or you have lots of memory to spare, this can still work. however, when the plug-in has allocated lots of memory and the plug-in relinquishes control to iMovie, Cocoa kicks back into action. and it may happen that it sees a block of memory it knows nothing of, and re-allocates it to something else. this is what we some people a memory management collision. you call it a crashing bug. what we call it we'd rather not put into writing. in a nutshell, this is why chromakey still works in some situation, and crashes in others.

now, however, the situation is becoming worse. as apple pushes ahead, they have taken the (quite logical) step, and also brought large chunks of QuickTime over to Cocoa and it's new memory manager. with each new OS release, more and more pieces are moved to new technology. although this progress is nice in many ways, it spells disaster for some of our plug-ins. for example, our 'mix/blend' and 'multiple movie' plug-ins utilize QuickTime. up until recently, this was safe. now, suddenly, QuickTime relies on Cocoa. each time we call QuickTime in our plug-in, we leave the confines of Carbon, and re-enter Cocoa-managed territory. since QuickTime manages a lot of memory (most videos are huge), this is a lot like dancing in a dense mine field. sooner rather than later, QuickTime will de-allocate an unknown (Carbon-owned) block of memory, and and take dive off the deep end.

that is the reason why with each progressive system update we have seen more and more of our sophisticated plug-ins become more and more unstable. now, it appears that we have to issue warnings with regard to 'mix/blend movies' and 'multiple movies'. since we can see the logical progress, anything that loads large chunks of memory will eventually be hit by this. this will include all our plug-ins that load external pictures and/or movies. be warned that with newer systems 'picture in clip', 'multiple picture', and 'simple mask' may become unreliable as well.

all in all it appears that in the case of our plug-ins, trouble is the coinage for progress, and we have to pay it. it doesn't mean we have to like it. here's to the slight hope that maybe it's worth it.

Posted: Mon - May 1, 2006 at 04:08 PM