On Mon, 2009-05-25 at 14:04 -0400, Jimmy Thrasher wrote: > Another possibility would be to remove the underlying animation logic > entirely and separate it out. > > <what-I-mean> > The libanim library, for example > (http://github.com/jtdubs/libanim/tree/master) assumes the concept of > animation is unrelated to the actual rendering or modeling frameworks > used. Rather, you set up values to be animated and ask it for the > values at time t. This allows you to do animations live, or render > them frame by frame to some file, etc. It separates concerns. > </what-I-mean>
I seriously doubt Clutter should depend on an external project that is a month old and while using GLib is not even using GTypes or GObjects. the pieces of the Clutter animation framework have been tested and iterated over for at least two years; they are integrated in the main loop used by Clutter and inside the paint cycle. while an animation API might look like a good candidate for abstraction, having it completely detached from the paint cycle of the GUI library using it is a recipe for bad performance. > Clutter could use libanim (or similar) and build its clutter-style > animations on top of it. which would probably entail rewriting most of the API and implementation one week before code freeze for the 1.0 API cycle. no, I seriously don't think so. > (p.s. I haven't thought this through). I assumed that much. ciao, Emmanuele. -- Emmanuele Bassi, Senior Engineer | [email protected] Intel Open Source Technology Center | http://oss.intel.com -- To unsubscribe send a mail to [email protected]
