Re: [clutter] Animations
On Thu, 2009-05-28 at 09:39 +0200, Jonas Bonn wrote: I found two small details to fix up in your version... I'll just submit them to the list as a single patch (trivial stuff). you should use bugzilla - I tend to loose track of stuff sent to the mailing list (it took me ages and a poke on IRC to get to look at your email :-)). ciao, Emmanuele. -- Emmanuele Bassi, Senior Engineer| emmanuele.ba...@intel.com Intel Open Source Technology Center | http://oss.intel.com -- To unsubscribe send a mail to clutter+unsubscr...@o-hand.com
Re: [clutter] Animations
On Wed, 2009-05-27 at 21:11 +0300, Henrik Hedberg wrote: Is there really a good reason to assign only one animation object to an actor and readjust that when the clutter_actor_animate* is called again, instead of creating separate animation objects for each call of the clutter_actor_animate*? I don't have anything against composition of multiple animations. the first implementation of the animate() function allowed composition; after some discussions in the office, I decided to remove that because we didn't have the API to stop an animation and avoid conflicting settings. after some months, the composition behaviour was brought up again, this time with more API and some use cases. as a matter of taste, for compositing animations I'd rather have an AnimationGroup and then a clutter_actor_animate_with_group() - more flexible, but obviously it would need to wait the 1.1/1.2 cycle. ciao, Emmanuele. -- Emmanuele Bassi, Senior Engineer| emmanuele.ba...@intel.com Intel Open Source Technology Center | http://oss.intel.com -- To unsubscribe send a mail to clutter+unsubscr...@o-hand.com
Re: [clutter] Animations
On Mon, 2009-05-25 at 14:46 +0200, Jonas Bonn wrote: Hi, I had a short discussion with ebassi on #clutter... we decided I would send an email detailing what I feel are some weaknesses in the Animation API/implementation. Thanks for considering this; my thoughts follow: An Animation currently keeps track of: timeline mode duration loop I agree that the Animation properties should not go out of sync with the underlying objects. personally, my take is that the Animation should: - cache the values in case the Alpha and/or the Timeline instances are not present, or if they are being replaced - proxy the values otherwise which is basically what are you proposing, except that I wouldn't remove the loop, duration and mode variables from AnimationPrivate. the behaviour of the Animation class would then match these invariants: - set_mode() + no alpha set: create an alpha (without a timeline) + alpha set: set the mode - set_duration(): + no alpha set: create an alpha, then a timeline + alpha set: get the timeline of the alpha, set duration - set_loop() + same as set_duration() - get_mode() - get_duration() - get_loop() + no alpha or no timeline are set: return the cached values + alpha or timeline set: return the alpha or timeline values for the set_alpha() and set_timeline() we need some more hand-holding, because we depend on instances to make the animation machinery work: - set_alpha(): + no alpha set and passed NULL, create alpha (without a timeline) + no alpha set and passed !NULL, own the alpha and use its timeline + alpha set and passed NULL, create alpha and reuse the timeline from the old alpha + alpha set and passed !NULL, own the alpha and use its timeline - set_timeline() + no alpha set and passed NULL: create alpha and timeline using stored values, and assign the timeline to the alpha + no alpha set and passed !NULL: create alpha and assign passed timeline to the alpha + alpha set and passed NULL: create timeline using stored values and assign it to the alpha + alpha set and passed !NULL: assign timeline to the alpha - get_alpha() + no alpha set: create an alpha using the stored values, with no timeline + alpha set: return alpha - get_timeline() + return the timeline assigned to the alpha in short: the Alpha should be available as soon as: - :mode, :duration or :loop are set - get_alpha() or get_timeline() are called while the Timeline will be available as soon as: - :duration or :loop are set I'll document this properly before the 1.0 release. I hope this makes some sense and I look forward to your comments. I'm happy to provide clarification where things are less than clear. thanks for your feedback! ciao, Emmanuele. -- Emmanuele Bassi, Senior Engineer| emmanuele.ba...@intel.com Intel Open Source Technology Center | http://oss.intel.com -- To unsubscribe send a mail to clutter+unsubscr...@o-hand.com
Re: [clutter] Animations
On Mon, 2009-05-25 at 21:14 +0300, Veli Ogla Sungutay wrote: I agree with you. This is how we deal with animations in Flash/Flex world with TWEENER. Tweener requires that the toolkit knows how to deal with the animation updates and has a system to integrate tweener updates within the paint cycle. Actually Tweener provides an interface, it's language agnostic, and can be ported to C and Clutter if necessary. there is very little that Clutter does not offer already, in terms of what Tweener provides. if at all. I know, for instance, that gnome-shell is using Tweener, but has replaced the FrameTicker with a Clutter Timeline instance running at 60fps. in theory, with 1.0, this won't work since a Timeline is not a timeout anymore but simply something that computes the intervals and emits the frame-changed signal whenever the redraw cycle is ready to begin. once 1.0 lands they will probably have to change to using a paint function to update all the tweening. or drop tweener and use the Animation API. ciao, Emmanuele. -- Emmanuele Bassi, Senior Engineer| emmanuele.ba...@intel.com Intel Open Source Technology Center | http://oss.intel.com -- To unsubscribe send a mail to clutter+unsubscr...@o-hand.com
Re: [clutter] Animations
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 Clutter could use libanim (or similar) and build its clutter-style animations on top of it. There would be no need for and alpha function or a timeline.. simply an animation (p.s. I haven't thought this through). Jimmy On Mon, May 25, 2009 at 8:46 AM, Jonas Bonn jo...@southpole.se wrote: Hi, I had a short discussion with ebassi on #clutter... we decided I would send an email detailing what I feel are some weaknesses in the Animation API/implementation. Thanks for considering this; my thoughts follow: An Animation currently keeps track of: timeline mode duration loop However, these four properties are actually properties of: i) The underlying Alpha object (mode, timeline) ii) The Alpha object's timeline (duration, loop) I am free to manipulate the Alpha object directly; I can call clutter_animation_get_alpha(...) and then set the Alpha properties directly. PROBLEM 1: The Animation does not watch the Alpha object for property changes, so direct manipulation of the Alpha's properties results in the Animation becoming out of sync with its Alpha. Concretely, this means that the Animation's timeline no longer mirrors the Alpha's timeline and likewise for the mode. POTENTIAL SOLUTION: Watch Alpha for property changes and update Animation accordingly. BUT: Why bother mirroring the properties? BETTER SOUTION: Just defer to the Alpha when querying/updating Animation properties... The same goes for the timeline. PROBLEM 2: I can manipulate the timeline externally, but the Animation does not watch for changes to timeline properties so the Timeline and Animation can get out of sync. POTENTIAL SOLUTION: Watch Timeline for property changes and update Animation accordingly... BUT: Again, why bother with the mirroring? BETTER SOLUTION: Just fall through to the Alpha's Timeline for querying/updating properties. As it stands today, when I call clutter_animation_set_timeline(animation, timeline), then the timeline will be stored in both the Animation and the Alpha. PROBLEM 3: The Alpha may have been set externally (e.g. with _animation_set_alpha(anim, alpha))... it should be made explicitly clear that setting the Animation's timeline has the side-effect of setting the Alpha's timeline. (This may surprise the user). POTENTIAL SOLUTION: Document this. BUT: Again, why bother storing the timeline in two places? BETTER SOLUTION: Document explicitly that that animation_set_timeline is just a helper function that sets the timeline on the underlying alpha. This way, there are no surprises. The API currently requires something like the following (note here the two calls to _set_timeline and _set_alpha with parameter NULL). anim = clutter_animation_new(); clutter_animation_set_object(anim, G_OBJECT(actor)); clutter_animation_set_duration(anim, 150); clutter_animation_set_mode(anim, CLUTTER_LINEAR); clutter_animation_set_timeline(anim, NULL); clutter_animation_set_alpha(anim, NULL); interval = clutter_interval_new(G_TYPE_UCHAR, 0, 255); clutter_animation_bind_interval(anim, opacity, interval); timeline = clutter_animation_get_timeline(anim); PROBLEM: If I forget to call _set_alpha, then the animation just silently fails to do anything. (I ran into this... took me a while to figure out). SOLUTION: An animation without an alpha is pretty useless... if the animation has no alpha when the user tries to run it, then we should set up a default alpha for him. This ties into the following point... PROBLEM: The two calls to _set_timeline and _set_alpha with parameter NULL should not be necessary as they are just invoking a default configuration. SOLUTION: Make clutter_animation_get_timeline() do the right thing by creating the necessary underlying Alpha and Timeline if they do not already exist. Then these two calls can go away. NOTE: (Given this solution) Generally, the underlying Alpha and Timeline will already exist before clutter_animation_get_timeline is called because they will need to be created in order to hold the other property values... see the notes that follow: NOTES: _set_duration: requires a timeline, so this function will implicity create an alpha and a timeline if they are not already set. _set_loop: requires a timeline, so same as for _set_duration _set_mode: requires an alpha, so this function will implicitly create an alpha if one is not already set. _set_timeline:
Re: [clutter] Animations not smooth
Hi; On Sun, 2008-07-06 at 21:52 +0200, Dirk Meyer wrote: I want to use imlib2 also for the reflection but I need the data from the texture. There seems to be no simple get_from_rgb_data function. Any plans to add that for 0.8? You can use cogl_texture_get_data() - but it would be faster to create the reflection when you initially have the data from imlib rather than uploading to texture memory and then re-downloading.. == Matthew -- To unsubscribe send a mail to [EMAIL PROTECTED]
Re: [clutter] Animations not smooth
WRT creating bindings for self-made actors, that is relatively straightforward. I have done similar things for the OCAML bindings I'm building. Basically, you need to follow the recipe for creating a new Gobject- based actor class as discussed in the Clutter documentation. Even better, you can copy some of the stuff implemented for the coglbox examples which used a private data structure in the object (you will need something like this). In the private data structure, you will need to keep references to all of the python closures/lambdas (whatever you call them:). In the foo_actor_init, you can pass in all of the python closures or Py_NULL or whatever for methods you don't want to implement. Then you write C functions that correspond to all of the routines that you might want to override. The C function will simply check the private structure to see if, for example the pick function has a python closure, and then invoke it with the appropriate arguments. I hope this helps. I can send you an incomplete example if it helps, but it will be for OCAML, so may not be that illuminating. WRT threads and cairo, I think you should be pretty safe as long as you implement it properly. I mean, you really just need to make sure that your thread is operating on its own Cairo context, maybe just to a backing pixmap. The you can blit this in using a Cairo.paint or other mechanism. - Reid -- To unsubscribe send a mail to [EMAIL PROTECTED]
Re: [clutter] Animations not smooth
Hi; On Fri, 2008-07-04 at 22:29 +0200, Dirk Meyer wrote: I have a grid widget (clutter.Group) with some images in it. All imges have a reflection. The reflection clutter.Texture is based on cairo (I took the code from entertainer or gloss). This means software rendering. It is possible to scroll in the grid widget. When I scroll down to a row not drawn yet I create the missing widgets on the fly. This means I create x images and x reflections. Doing that makes the scroll animation not smooth anymore. The reason is simple: it takes some time to load the images and way too much time to render the reflection. For the first problem I could use some async loader stuff from gdkpixmap, but how to solve the reflection delay? I'm not allowed to do that in a thread but I'm still thinking of a way to do it anyway (is cairo thread-safe?). Some rough thoughts from me (note, I know nothing about bindings..). Rendering with Cairo in Clutter, in terms of at least creating the initial texture isn't accelerated, its all currently done in software. One thought on how you could create a basic reflection effect with out any subclassing, cairo etc is clone the source texture, then flip it 180 around X axis and then overlay a pre built cloned texture with a background color to alpha gradient. That would only work though if beneath all that is a solid colour. For images, You could have a worker thread loading the actual images and then pushing the actual data to the texture in the main thread (or using gdkpixbuf async stuff) and just have stub image or 'proxy' type texture in there to begin with. == Matthew -- To unsubscribe send a mail to [EMAIL PROTECTED]
