[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Playing with Gears
From: |
Richard Frith-Macdonald |
Subject: |
Playing with Gears |
Date: |
Wed, 14 Feb 2007 10:59:43 +0000 |
I made some time to play about a bit with your Gars app ... http://
amstradstuff.free.fr/GNUstep/gnustep-gears-1.0.tar.gz
This is a really nice demo application, very impressive.
Some observations on the options provided for animating.
1. pure timer based animation... the repeat interval set for the
timer is 0.0 seconds.
This means that, as soon as a timer is fires, it is put back in the
runloop's of timers available to be fired immediately, and hence
fires again repeatedly and the runloop never gets a chance to run.
That prevents any other event from occurring and means that the app
locks up apart from displaying the animation.
This is a reasonable behavior, but may not be what macOS-X does ...
we should probably test MacOS-X to see what it does in
limitDateForMode:. The other possible behavior is that timers added
as a result of a timer firing are deferred until the next runloop
iteration. That would prevent an app from locking itsself up with
instantly repeated timers or timers added when other timers fire.
2. performer based animation
Using a performer has different consequences ... performers are
defined to fire at the start of the *next* runloop iteration, so when
a performer fires, does the animation, and sets up another performer,
you are guaranteed that it won't stop events coming in, but you have
the disadvantage that, if no events arrive for a while in the current
loop, your animation won't get called either ... so this mechanism is
simply unsuitable for animation. Again, it's possible that MacOS-X
behaves differently, but given that the documentation explicitly
states that the performer is fires in the *next* runloop iteration ,
it's likely that the MacOS-X and GNUstep implementations behave the
same way.
3. event based animation
In this one, the animation routine posts an event to animate again as
soon as the animation is done ... which means that there is always an
event in the event queue to trigger another frame of animation. I
would expect that to produce the same effect as with the timer with a
repeat interval of 0, but it actually seems to work normally, so I
guess that something in the animation code is causing new events to
be added to the event queue before the post event is done. It may be
that this is the backend adding events without calling the
runloop ... in which case this mode is actually similar to the timer
one (in that the runloop is never given a chance to run), or it may
be that the backend is calling the runloop and adding events from the
X server, I can't easily tell.
I haven't looked at all at the implementation at the events+performer
or events+timer options.
Anyway, it seems to me that we don't really have a fully satisfactory
way to do animation yet:
Running a timer too fast will lock up everything else
Running a timer too slow will mean fewer fps than we ought to be able
to achieve
Using performers is just going to make animation wait for runloop
events to come in and be jerky (frozen if there are no events)
Event based animation looks OK, but might not be letting the runloop
run, in which case we would have problems in an app which needs the
runloop to run to do other jobs.
I think we need to investigate timer behavior on MacOS-X ... if we
changed the behavior of timers we might get decent animation behavior
using that ... I have a feeling that timers *ought* to be the way to
do animation, and that perhaps our behavior when we add/repeat a
timer so that it goers out immediately is wrong (maybe timers added/
repeated by a timer being fired should not themselves be fired until
the loop has run).
I think also think we need to investigate what is happening in the
backend with event based animation... I don't believe that the
backend should be adding events to the event queue without running
the runloop first, so we should check to see if this is occurring.
- Playing with Gears,
Richard Frith-Macdonald <=