LiTE Timeouts and Idle Callbacks

LiTE's event loop supports two mechanisms that notify your application where there are no events to be processed.

= Timeout Callbacks =

A LiTE Timeout is a one-time callback function that you register to be called sometime in the future. This is done using the  API from window.h.  This timeout callback will be called exactly one time after "timeout" milliseconds. Note: the time provided is a minimum wait time -- processing events from DFB has priority and no timeouts will be called until the event queue is empty.

While a timeout callback is being processed, no other events or timeouts will be processed, so don't do anything that takes extensive CPU time here. If you need the timeout to reoccur, it is safe to call  to enqueue another timeout while processing the current timeout.

The mechanism used at the low-level to support this is based on a call to pthread_cond_timedwait in the DirectFB code. This API is affected by any system time changes, so changing the time-of-day while a timeout is active is unpredictable.

= Idle Callbacks =

The  API lets you register a one-time callback that is called by LiTE when there are no pending events or timeouts needing to be called. This might be used by to do background processing in a system. While you can re-register yourself in the idle callback routine, some users prefer to do some processing, then setup a timeout callback to continue the processing after allowing the system to sleep.

= LiTE Event Loop Priority =

The LiTE Event Loop works on a fixed priority system. On each pass, it processes things in this order


 * 1) is the event loop alive?  if not, exit (you can force the event loop to exit using lite_exit_event_loop)
 * 2) are there any DirectFB events to process?  if so, fetch, dispatch, and restart event loop
 * 3) are there any pending updates to be drawn?  if so, draw them
 * 4) are there any timeout callbacks that are ready to be called?  If so, call the first one then restart event loop
 * 5) are there any idle callbacks?  If so, call the first one then restart the event loop.
 * 6) go to sleep until either the next timeout callback is ready or new event arrives

= Future Direction =

We are working on complicating the event loop slightly. An API will be provided that will cause DFB to requires that windows update at least every N milliseconds. This will allow you to get visual feedback without directly drawing the window while processing a large queue of events.