nanogui: TIMERS


Previous by date: 11 Jan 2006 20:50:47 +0000 Re: TIMERS, Alex Holden
Next by date: 11 Jan 2006 20:50:47 +0000 Space padded text, webpal.justdave.us
Previous in thread: 11 Jan 2006 20:50:47 +0000 Re: TIMERS, Alex Holden
Next in thread: 11 Jan 2006 20:50:47 +0000 Timers, Dave Stuart

Subject: Re: [nanogui] TIMERS
From: "Greg Haerr" ####@####.####
Date: 11 Jan 2006 20:50:47 +0000
Message-Id: <0f0701c616f0$9b002d40$0300a8c0@RDP>

: What's the story on timers (GrCreateTimer, GrdestroyTimer,...)? Are they
working?

Yes.  Note that there are only the above two timer APIs for
creating or destroying a seperate timer.  In some of your messages,
you imply callback functions etc.  These are for the GdXXX timer
functions, which are "engine-level" and not accessible to the
nano-X applications programmer.

: Could someone briefly give me an overview of how the timer system works?
I'm almost sure a timer is being created but it appears that the event is
never fired, if GsTimerCB is indeed the timer callback.

It's very simple: All timers work by sending a
GR_EVENT_TYPE_TIMEOUT event to the application
event queue.  You can create a periodic (continual) timer
using GrCreateTimer(), or you can wait just once for a
timer using GrGetNextEventTimeout().  A periodic timer
is terminated using GrDestroyTimer().

These API functions are simpler than those Alex originally
contributed, in that there is no option for whether a
timer created via GrCreateTimer is periodic.  It always is.
Should you want a one-shot timer, use GrGetNextEventTimeout,
or destroy the timer in the first event message.

Note, GsTimerCB is an internal function, used only with the GdXXX
routines internally.



: There is a dcumentation that there may be other timer event queued and the
client must be able to handle late timer events. Is this something the app
have to keep track of?

All this means is that the server may send a timeout event, and the
client may be off doing something.  If the client doesn't get around
to servicing the first event before the server generates another, then,
whaddya know, you've now got two timer events in the queue.

: I just took a look at the current CVS version of Microwindows, and it
appears that the integration of my improved timer code was never
completed. The demos for both timer types are there, and a modified
version of the core timer code for both timer types is there (though
oddly it replaces one function with a flag argument with two nearly
identical functions), but GrCreateTimer() doesn't have the flag
argument that lets you choose which timer type to use.

The timer code has been in Microwindows for some time, and
works.  There were two contributions for timers.  I ended up
simplifying the nano-X timer API (described above), and using
a very slightly modified version of Alex's internal timer-handling
code. (internally, we support one-shot and periodic timers, for
server use only).

: Polling GrCheckNextEvent() and calling an 'idle' function every time
you receive a GR_EVENT_TYPE_NONE is an unusual way of doing things.
Because there isn't a delay of any sort in idle(), you'll end up
calling it over and over as fast as possible using 100% CPU. Better
to do a GrGetNextEvent() and wait for an event to come in.

This comment by Alex is correct.  You are likely having strange issues
with the timer code, because you're buzz-looping on GrCheckEvent,
rather than hanging in GrGetNextEvent{Timeout}.  This could be
a bug in nano-X, in that the timeout code isn't handled correctly
durring Peek and CheckEvents.  Also, if you look closely at
the implementation, for certain reasons, in CheckEvent only,
timeout events are returned as no event (EVENT_NONE).
Thus, I heartily agree with Alex's advice.

Hopefully, this and Alex's comments clear up your misunderstanding
of timers.

Regards,

Greg

















Previous by date: 11 Jan 2006 20:50:47 +0000 Re: TIMERS, Alex Holden
Next by date: 11 Jan 2006 20:50:47 +0000 Space padded text, webpal.justdave.us
Previous in thread: 11 Jan 2006 20:50:47 +0000 Re: TIMERS, Alex Holden
Next in thread: 11 Jan 2006 20:50:47 +0000 Timers, Dave Stuart


Powered by ezmlm-browse 0.20.