Thu 15 Jan 2009 03:40:28 PM UTC, comment #1:
I've spent a long time looking at this, and now rather suspect that NSAnimation is at fault here rather than NSRunLoop, and fixing a bug in NSRunLoop has exposed the problem in NSAnimation.
The Cocoa docs specifically state that runMode:beforeDate: returns NO without running the loop if the loop has no input sources, but don't say clearly what acceptInputForMode:beforeDate: does. In gnustep-base it now matches the MacOS-X implementation (to return immediately if there are no input sources). I checked these behaviors using a small test program on MacOS-X. It's a bit confusing because a naive test (using NSDefaultRunLoopMode) appears to give a different result from the documentation. I think we have to assume that MacOS-X generally has its own input sources in the default run loop mode ... perhaps we should emulate that or find out more somehow. In any case, this should not effect the animation code as it's not using the default run loop mode.
Now, I've currently left -runMode:beforeDate: broken (it returns YES when there are no input sources) because I think the correct behavior (returning NO) was causing the animation code to stop.
However, the animation still doesn't look good, and I think that's because acceptInputForMode:beforeDate: now returns immediately when there are no input sources, and this means that the animation code is doing a busy wait (calling the method repeatedly) and so using up all the CPU and making the actual drawing slow and jerky.
So my guess at a proper fix is that the animation code should be modified to:
1. keep repeatedly calling -runMode:beforeDate: until it should terminate, irrespective of the return value.
2. put some sort of delay into the code to animate at the correct rate and stop it consuming all of the cpu.
However, I'd like someone else to confirm the diagnosis.
|