Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [nebula-dev] Animation framework

Replies below...


From: Ivan Ooi
Sent: Sunday, January 18, 2009 6:29 PM

 

Nice if able to come out some thing similar to

http://www.smartclient.com/smartgwt/showcase/#effects_animation_move

[Roland Tepp] Yes, most of the move and resize effects are easily doable. Fade in/out are currently not due to the fact that SWT widgets in 3.2 do not support setting their alpha values.

 

From: Jeremy Dowdall
Sent: Monday, January 19, 2009 2:51 AM

Hi Roland,

A few of points about the framework that came to mind:

  1. You did mention animating any property on any object, and I want to stress that point further.  The document describes a good framework for consumers of widgets, but not necessarily for use within widgets, which is far more important for a Nebula hosted project, especially as SWT is supposedly working on a framework of their own.  The core of the framework really needs to be abstracted out to just be a value changing at specific time intervals.

[Roland Tepp] Well – ma reasoning not to limit myself to only SWT widgets was born out of the practical notion that there are things I just can not do with SWT (like alpha blending, table row item reordering animations, etc.) that I might need to emulate on a completely custom drawn widget/layer, so I simply did away with any assumptions on what it is exactly that I am animating.

The AP itself is loosely modeled after some examples I saw in dabbling with Flash/Flex jQuery and WPF/Silverlight.

At the core there is an abstraction of an animation that has actually nothiong to do with anything else than processing animation events like starting, stopping, pausing and resuming animations. The animator acts as a sort of a concertmaster (or more aptly choreographer) of the whole animation and calls frame events on the running animation(s). The only concrete types of animations that are defined in the core api are Parallel and Sequence, which provide parallel and sequential execution of the animations they contain. And Tween, which is an abstract base class for simple „tweening“ animations like Move, Resize, Foreground, Background.

  1. Frame dropping.  We can't be guaranteed what else will be going on when we try to animate something - if the system falls behind we don't want to waste time with frames that are out of date so we'll need a way to identify this and gracefully skip them.  I've done this in _javascript_ by giving each initiated frame an ID, the animator keeps track of the active ID and if a frame comes due with an older ID it simply returns.

[Roland Tepp] To be honest, I have not thought of that aspect, although I suppose that with the API I have, this feature should not be all that difficult to add...

  1. Cancellation.  Quite often something may start to open and then be requested to close before it is finished.  Locking the animation to not perform the close until the open is complete is a workable start, but not what is intended.

[Roland Tepp] Every animation has four public methods: start, stop, pause and resume, so cancelling a specific animation in a larger animation quite possible but (in fact, I did just that quite recently and it works like a charm).

  1. Inject runnables right into the chain of events: close_animation -> runnable(set text) -> open_animation.  The Listeners you mention can be used for this, but something about it seems awkward.

[Roland Tepp] Well – Listeners are designed just for that, but You can also just write your own „animation“ class that does nothing else but execute a runnalbe (preferably in a separate thread, as all the animation framess run by necessity inside UI thread) and once  the runnable finishes, move the animation into the „finished“ state.

  1. The pluggable easing strategies look quite flexible, but would they allow me to do a completely custom animation path?  Here's some reference for this: http://www.w3.org/TR/SVG/animate.html#AnimateMotionElement.

[Roland Tepp] easing strategy is actually nothing else but a function that defines the acceleration of the movement across it’s movement path. If you want the path to be a curve, you have to write your animation implementation that maps one-dimensional „position“ (that Easing operates on) to a point in two- (or 3-) dimensional plane. Move and Resize are just simplest of such animations (their movement path being linear).




 


Back to the top