Re: [bug #25327] NSAnimation no longer works

[Benhur Stein]

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
<INVALID.NOREPLY@gnu.org> 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
> Bug-gnustep@gnu.org
> http://lists.gnu.org/mailman/listinfo/bug-gnustep
>