Re: Playing with Gears

[Fred Kiefer]

I just gave gear a try under MacOSX and it works wonderful. All I needed
to change was replace GL/gl.h with OpenGL/gl.h and include the GNustep
macros from GNUstep.h. Marvellous how portable applications can be.

All three animation models (or rather all five, as combinations are
implemented as well) work on Cocoa. Performer is rather slow, when there
a no new events generated and the others stop to work as soon as you
open up the menu. But the menu works in all cases, so there is a
difference to the GNUstep implementation.

Great example!
Fred

Richard Frith-Macdonald schrieb:
> 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.
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Gnustep-dev mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/gnustep-dev
>