Memory model in new Animator classes

[Adenilson Cavalcanti]

Dear Mehmet

Thanks for commenting I will try to address the questions.


> 
> If you think about the use cases, I don't think we'll ever
> see thousands or
> even hundreds of animations running at the same time. I
> don't think the
> memory savings is significant at all in this situation
> anyway, so less
> processing time might be nice to aim for, especially in
> stuff like hover
> menus where multiple things are animating at the same time
> and we want it to
> look very smooth. Maybe you can store the
> QPropertyAnimation inside the
> Animation object for later reuse? But if you do that, what
> happens if I want
> to apply the same animation with the same parameters to
> several objects?
> Maybe store several QPropertyAnimations internally? It
> starts getting a bit
> messy.

Yep, we can store it and reuse (and say when the user sets a new widget to be animated, re-create the QPropertyAnimation on demand).

So the memory footprint would be just 1 QPropertyAnimation along the time. 

> 
> I'm not sure if you can "rewind" per se, but as Morpheuz
> says, you can use
> states for the initial and the final situation of the
> object and add a
> transition animation and then switch back and forth between
> those states.
> But then you need to create states each time and keep track
> of them.

Yes, check QAbstractAnimation::setDirection(), as a matter of fact we even used it in the PoC contacts plasmoid (http://repo.or.cz/w/contacts_plasmoid.git). 

It is possible to call setDirection(QAbstractAnimation::Backward) and then run the animation again to return to previous state.

Anyway, I think we should explore state machines (maybe when dealing with grouped animations).


Best regards


Adenilson Cavalcanti