>
> I'll be happy to send this to anyone who'd like to see it or try it on
> their machine or experiment with changes. Much as I'd like to know
> exactly what's going on, I'm more interested (as I'm sure Gary is, too)
> in finding an acceptable workaround.
>
>

Thanks for sending the code, it makes it alot easier to find the problem.  After a quick trip to MacsBug, I found that "INKEY$" calls GetNextEvent inside the runtime.  This also explains why allowing a few events out first doesn't completely solve the problem - The OS knows that if the runtime said WaitNextEvent (with some really huge timeout), it would have enough time to tell Mr. Finder to go ahead and re-draw the desktop.  But GetNextEvent means "only do small things, we are in a rush" - until, that is, the Finder finally gets the big slice of time it needs, and whamo! there goes your animation speed.

Simple Workaround:
Remove INKEY$ and use GetKeys if you really want all the processing speed you can get

Better Workaround:
Use the TimeManager to schedule drawing of frames at a set interval, allowing other apps to do what they need in the interval between frames

Best Workaround:
Now that the animation experts on the list know whats going on, I hope they will come-up with the best solution....

Jamin