As mentioned earlier, these days, I've been thinking about animation issues. It seems the free world lacks an animation library that abstracts out the complexities of animations. A lot of libraries implement their own animation routines, which are generally incomplete and often unusable in other contexts than these libraries. I feel that we need (and I am ready to work on developing) a library that implements a good animation framework, and would provide the following functionalities:
  • a timeline, similar to what is implemented in QTimeline or GtkTimeline
  • an animation object, that handles the evolution of the animated variables from an evolution function, that could be constructed using...
  • an interpolator, that could interpolate in different modes (linear, bezier splines, cubic hermite splines, ...) between key values/times/speeds/accelerations.
Also, we could add another functionality, a bit less generic:
  • facilities for implicit animations on GObject properties. This would dramatically ease the creation of animations, especially in language bindings (I'm thinking at least of Python here).
And I want to respect the following constraints:
  • depend only on GLib.
  • easily bindable.
  • easy to use with any library (be it in C or in a language for which there is a binding for this library).
  • easy to use with a C/GObject library (think of GTK+, Pigment or Clutter).
Since I like silly names, I've decided to call it the "PAF Animation Framework" or PAF for short. You can find what I have done so far on a bzr branch: bzr branch http://emont.org/paf/ The only interesting stuff so far is paf.xmi and the stuff in examples/. Here is what this could look like, in Python, for a GObject image that has a property 'x' defining it's horizontal position: # Move @image's x position linearly to @dest. Implicit version. def implicitly_move_image (image, dest): animator = paf.ImplicitAnimator(image) animator.x = dest I have still many things to figure out and to improve, but that's already a start and I plan to actively work on this, since we badly need that for Pigment. When I start to be happy with the API, I will write the documentation and some empty C/GObject code, so that the output of gtk-doc can be used as a basis for discussion. Of course, anyone is welcome to participate in this effort, feel free to branch and to send me patch/address of other branches. This will be LGPLv2.1 or later, unless I find good reasons to publish it under LGPLv3. Please contact me if you have any comments, ideas questions or patches on this blog, on freenode/#pigment or by email (guillaume at fluendo dot com).

No comment

Post a comment

All comments are held for moderation; basic HTML formatting accepted.

Name: (required)
E-mail: (required, not published)
Website: (optional)

Published

10 March 2008

Tags