Apparently since the dawn of time, Director has had quite an affinity for the processor and its cycles. In fact, Director appears to like the processor so much that when running, there is little to no free processor time. In the old days, Director on the Mac had CPUHogticks to determine an amount of time to give back to the processor, but nowadays that command doesn't exist and CPU hogging becomes an issue for the following reasons:

• On laptops, hogging the processor will result in 100% processor allocation, which will result in a hot processor, which will turn the fan and lessen battery life.
• On OS X, your whole system becomes less snappy.
• Director does not play well with other applications if it asks for all the remaining processor power and may take processor power away from other subsystems that the projector may access.
• Hogging the processor makes distributing Director utility applications unrealistic.

From several conversations last century with various Director engineers, I learned several things. Among them, the movie-level Idle handler is only called when Director has nothing else to do or has spare cycles. This means that at times Director has spare cycles, cycles that could be used by other applications. Also, if Idle is called and completes, and there are spare cycles left, Idle will be called again and again until there are no spare cycles present, thereby keeping the spare cycles from being used by other processes. This will happen whether you have put an Idle handler in your movie or not. Following this logic, it would seem that if we were able to trap this Idle event in an Idle handler and sleep Director for an appropriately small period, then Director would not be gobbling cycles. Since it wasn't using them anyway this would free up the processor for other tasks and still allow Director to operate as fast as it needs to!

Now I know you're saying "Oh, that sounds lovely Sparky, how do you suggest we do this?" And this, gentle reader, is the good part.

From a conversation with Warren Ockrassa about his love of undocumented Xtras, I started playing around with one of those Xtras. In it I found a sleep command. Amply caffeinated, an aha moment happened and I decided to see what would happen if Director slept for 1 millisecond when Idle was called.

That was it.

This simple handler stopped Director from hogging the processor.

On Idle
sleep 1
end

If you run or produce Director software for OS X, this has profound effects, all of them good. Director running on Windows also exhibits better processor usage but the benefits are less pronounced.

The trick is that whether running a Director movie on the stage or in a MIAW, there is only a limited amount of idle or free time that Director can use as an opportunity to call Idle. This means that only one of these Idle handlers is needed for any Director session. More than one Idle handler split between the stage and any running MIAWs is not needed.

Now, the tricky part is that this afore unmentioned Xtra, which comes from Macromedia, has different names in different versions and platforms of Director. Great.

It started out as the "UI Helper Xtra", made to support Director's Export to Java functionality in D7. In Director MX, it was renamed the "Watcher Helper Xtra". On Windows, it was originally called "JavaUIHelper.x32". On certain versions of Director for Windows (8, 8.5), this xtra must be installed off of the goodies or xtra partners folder on the Director install CD. As far as I know, it is called "WatcherHelper.x32" on DMX for Windows.

In any case, you can always go to the message window and type the following line to see if the xtra you suspect has the sleep method in it.

put interface(xtra "the name of the xtra I suspect is the one I care about")

Once you have identified the xtra for the version of Director you are using, you must manually include the xtra in the movie xtras list for use within a projector since it is not an asset xtra.

Now make your projector, launch it, and run a processor monitoring app. You'll be pleasantly surprised. Image I provides a snapshot of a DMX projector playing nice with other apps on my 1G Ti PB.

A projector using only 11% of the CPU is a joyous site to see.

Think we're done yet?

There are caveats though and, luckily, solutions. Colin Holgate mentioned that this technique is great unless your projector is set to "not animate in the background." Sure enough, when I tested it a no animate projector on OS X started eating up all the processor power when put into the background. Colin's solution to this was to use a regular "animate in background" projector and to trap the activateApplication and deactivate-Application handlers. Within those handlers, set a global used for the sleep value to 1 on activateApplication and to a higher number on deactivate-Application. This technique combined with a regular animate in background projector allows the projector free up even more time when in the background.

Requested since before the dawn of time, the end to CPU hogging in authoring and projectors is here.

Enjoy.

Thanks for contributing to this discovery/technique go to Warren Ockrassa for general troublemaking and research; Joe Siponen (pointing out the xtra name differences between versions); Troy Rollins (MIAW experiments); and Colin Holgate (by default). Members of a number of Director-oriented mailing lists also helped flesh out this technique.