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