Excerpts from Zajcev Evgeny's message of Tue Mar 01 13:47:41 +0000 2011: > Robert Bragg <[email protected]> writes: > > [..] > > > I think in some game engines it is true that framerate variation can > > have a severe impact on animations since some game engines actually > > update animations in step with the framerate with a fixed progression of > > game time. (E.g. you used to see this kind of thing with quake such that > > animations could complete faster with a higher framerate) > > Great feature to have in clutter is externally driven master-clock for > this kind of purposes! Externally driven master clock is also > valueable when application is driven by another event loop > implementation, say libev. This might be a quite tricky part > integrating glib's event loop into libev.
Glib's main loop API is fairly flexible in this regard. You can manually iterate a GMainContext via g_main_context_iteration for instance and you can also replace the poll() function that glib uses internally when blocking for file descriptors using g_main_context_set_poll_func() which can be used to proxy those file descriptors into a different mainloop library. One thing I'd like our master clock to support though is an external time source. For debugging purposes for example I'd like to run an app in half-time or less to slow animations down or if I want to record Clutter content to a video I wouldn't want Clutter to follow real world time and drop frames. kind regards, - Robert -- Robert Bragg, Intel Open Source Technology Center _______________________________________________ clutter-app-devel-list mailing list [email protected] http://lists.clutter-project.org/listinfo/clutter-app-devel-list
