Starting from the 2.27 cycle, GLib is exposing a monotonic clock with
microseconds granularity throughout the time-based API. We can start
using it, given that the old, non-monotonic version is going to be
deprecated by the same cycle.
GLib 2.28 will deprecate GTimeVal and related API in favour of
standardizing on microseconds granularity for all time-based API.
Clutter should switch too.
All of the current users of GTimeVal convert to milliseconds when
doing time operations, and use GTimeVal only as storage. This can
effectively be replaced by a gint64.
The Master Clock uses a microsecond resolution, except when interacting
with the main loop itself, since the main loop has a millisecond
resolution - at least until Ryan Lortie manages to switch that too to
microseconds on Linux.
The clutter_timeline_do_tick() function was erroneously not privatized,
but it was still assumed to be private; we should just remove it from
the public symbols.
Since using addresses that might change is something that finally
the FSF acknowledge as a plausible scenario (after changing address
twice), the license blurb in the source files should use the URI
for getting the license in case the library did not come with it.
Not that URIs cannot possibly change, but at least it's easier to
set up a redirection at the same place.
As a side note: this commit closes the oldes bug in Clutter's bug
report tool.
http://bugzilla.openedhand.com/show_bug.cgi?id=521
The TimeoutPool is not used by ClutterTimeline any more, so we need to
remove a sentence from its description. We also need to fix the gtk-doc
syntax errors.
Bug 1495 - Timelines run 4% short
Previously the timelines were timed by calculating the interval
between each frame stored as an integer number of milliseconds so some
precision is lost. For example, requesting 60 frames per second gets
converted to 16 ms per frame which is actually 62.5 frames per
second. This makes the timeline shorter by 4%.
This patch merges the common code for timing from the timeout pools
and frame sources into an internal clutter-timeout-interval file. This
stores the interval directly as the FPS and counts the number of
frames that have been reached instead of the elapsed time.
Bug 1154 - clutter_timeout_pool_new() documentation doesn't say
how to free
* clutter/clutter-timeout-pool.c: Update the documentation to
note that you must use g_source_unref() to free the timeout
pool. (Murray Cumming)
* clutter/clutter-frame-source.h:
* clutter/clutter-frame-source.c:
New files that contain a replacement for g_timeout that try to
cope with system delays.
* clutter/Makefile.am: Added clutter-frame-source.{c,h}
* clutter/clutter-timeline.c (timeout_add): Use a frame source
instead of a g_timeout.
* clutter/clutter-main.c (clutter_threads_add_frame_source_full)
(clutter_threads_add_frame_source): New public functions to wrap a
frame source and grab the Clutter mutex.
* clutter/clutter-timeout-pool.c: Now calculates the timeout
expiration times in the same way as a frame source does so that it
counts time in frame intervals instead of setting the next
expiration time as an offset from the current time.
The clutter_timeout_pool_insert_sorted() function caused an inversion of
the timeout sources in the pool; this led to a wrong behaviour in the
execution of the timeout functions. See bug 471.
This patch drops clutter_timeout_pool_insert_sorted() in favour of the
standard g_list_insert_sorted(), which produces identical behaviours with
and without the pool.
A new test, written by Rob Bradford, has been added to the regression test
suite in order to identify sorting issues with the timeout pools.
* clutter/clutter-timeout-pool.c: Fix removing and adding timeouts
to the timeout pool during a dispatch of a timeout source already
inside the pool. (#456, based on a patch by Neil Roberts)
(clutter_timeout_dispatch), (clutter_timeout_pool_dispatch): Hold
the main Clutter lock in the pool dispatch function, instead of
the per-timeout dispatch; this guarantees that the ref+unref of
the single timeouts are done under the main lock.
All the ClutterTimeline share a ClutterTimeoutPool by default. This might
cause problems if an application is using a heavily threaded library that
does not play nicely with the main loop (like libneon). If this is the
case, using the CLUTTER_TIMELINE environment variable set to "no-pool"
makes the ClutterTimeline objects discard the pool and allocate a slice
of the main loop.
The mutex protection for the timeout pool was causing deadlocks, so it has been
removed for the time being, until I figure out a way to make it work properly.
A timeout pool should not be considered thread-safe (or thread-aware) until further
notice.
* clutter/clutter-timeout-pool.c: Make ClutterTimeoutPool
more thread-safe, using a static lock.
(clutter_timeout_pool_dispatch), (clutter_timeout_pool_remove): Fix
a race condition-turned-in-memory corruption bug, triggered by
removing a timeout from the pool while still spinning the pool
source.
A ClutterTimeoutPool is a source for the GLib main loop which pools
multiple timeout functions. The pool is always sorted so that the first
timeout to expire is also the first element of the pool; hence, extraction
is a constant time operation. This also makes the usage of multiple
timeouts at the same priority not compete for a timeslice of the main
loop, leading to starvation.
