Isadora 1.3 update

An update from the creator and owner, some interesting comments for both mac and windows users:

“Dear Users,

I am writing to give you all an update on the final version of 1.3. My goal was to have this out on August 1st, but it’s been full month since then — a month where I’ve been working quite literally 80+ hours per week to nail some very tricky problems. I am only now thinking that I’ve finally got things nailed down.

The short story is that I have been attempting to ensure 1) movie playback is totally glitchless and 2) Isadora is truly crash-free, 24/7 application. While I’m sorry to delay a release, these two points are critical for the future of the software. I’m happy to report that the major problems I’ve encountered seem to be under control, and I hope to release the true “final candidate” in the next week or two. From that point on, it will only be bug fixes.

Below is a detailed tale of what’s been going on in August for me. Please read on if you are curious.

Gory Details

The biggest problem was that a user discovered that Isadora 1.3.0f17 had a “memory leak” — where chunks of memory that are not properly disposed gradually build up and eventually cause this system to crash.

N.B.: below I’ll be mentioning the word “thread” a lot — a thread is a like a sub-program that runs in parallel to the main program. The idea is that when one thread is waiting for a resource (e.g., the hard drive) one of the other threads can be doing something useful. More geek-tastic details can be found here. In any case…

After two+ weeks of digging, I found out that the memory leak was not in Isadora but in QuickTime. (Though, to be fair here, the way I started to preload movies in a background thread in 1.3.0f17 is non-standard; nevertheless Apple’s code shouldn’t leak memory — you can see my unanswered question to Apple here. Though sheer trial and error of about one million combinations, I think I’ve found a way to play the movies and not leak memory. One recent test (very heavy patches with multiple HD clips that are frequently changing, etc.) ran for three days without any trouble.

It actually still leaks 16 bytes every time you start a movie. There’s simply no way around this bug in QuickTime. But hopefully that small amount will take weeks to accumulate to the point where the software will crash.

My other goal was to release a version of Isadora that simply never glitches. This was another big problem for many reasons, perhaps most notably because the call that disposes a QuickTime movie can take 45 mS or even more — obviously much longer than one frame. I attempted to put this Dispose into a background thread too, but this has proved to be very crash prone.

So, I put my energy into the threaded movie playback feature — where each movie ‘lives’ completely inside its own thread — and this has yielded some very powerful results. This feature is now very strong Mac OS. Furthermore, threaded playback will ensure that the work of playing movies is more evenly distributed across the processors in your system and it helps to ensure better consistency as to the delivery of frames to the output device.

Under Windows, I’ve also had success with threaded movie playback. But I need to do some very serious testing, because QuickTime for Windows absolutely does not support playing movies in a background thread. Everything I’m doing is totally “illegal” according to the documentation — yet, I’ve got it working to a certain extent. More to come on that front.

But the real answer for Windows is to enable the Native Movie Playback and let Windows play the clips for you instead of QuickTime. Microsoft’s code is already heavily threaded, and the performance is just loads better than QuickTime, especially for HD clips. I’ve been testing on Windows using the native playback, and it is just simply better. The downside is that the Direct Show SDK (MS’s code that allows me to play movies) simply doesn’t support some of the stuff that QuickTime does, e.g., playing movies backward. Or things that don’t work well, like changing the play start/play length is super-ugly in terms of its behavior.

Well, that’s what’s been going on. Hopefully you’ll see the final candidate very soon.”

This was taken from a post on the troika tronix forum:


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s