If someone looks into NSAnimation, it is worth reviewing its memory management. I tried to use NSAnimation some time ago, and gave up because it was leaking memory. I did a quick look at it at the time, and there is a retain cycle between NSAnimation and GSAnimator. When I broke this (by removing the retaining of NSAnimation in GSAnimator), I just went a bit further until another retain cycle, and I gave up as I did not have enough time, and changed my code to not use it. My intention was to come back and try harder to find this or at least file a bug report, but I did neither...
On Thu, Jan 15, 2009 at 1:40 PM, Richard Frith-Macdonald <[email protected]> wrote: > > Follow-up Comment #1, bug #25327 (project gnustep): > > 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. > > > > _______________________________________________________ > > Reply to this item at: > > <http://savannah.gnu.org/bugs/?25327> > > _______________________________________________ > Message sent via/by Savannah > http://savannah.gnu.org/ > > > > _______________________________________________ > Bug-gnustep mailing list > [email protected] > http://lists.gnu.org/mailman/listinfo/bug-gnustep > _______________________________________________ Bug-gnustep mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-gnustep
