[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug #25327] NSAnimation no longer works
From: |
Richard Frith-Macdonald |
Subject: |
[bug #25327] NSAnimation no longer works |
Date: |
Thu, 15 Jan 2009 15:40:29 +0000 |
User-agent: |
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_6; en-us) AppleWebKit/525.27.1 (KHTML, like Gecko) Version/3.2.1 Safari/525.27.1 |
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/