It’s ugly when the animation engine and layout engine fight.
Originally, I wanted the “new user…” label to animate into position between the welcome screen and the new user screen. As it turns out, moving the label while its parent container is moving leads to some jagged animation.
Stare at the label as you go through the animation. Notice how it appears to jump up and down? I had to ask a lot of questions before I got to the bottom of the issue. When animations run in parallel, do all tweens update at the same time? Yes, theoretically. If there isn’t enough time between frames to do all the updates, do some of the updates get dropped? No, the answer is that the frame is delayed. etc., etc.
The answer, as it turns out, is obvious in hindsight. It has to do with the layout managers and how they work.
~
Certain properties, such as the position of elements relative to their parents, are wired up directly to the underlying Flash Player display list. That means that when these properties are updated, the Flash Player automatically displays the new results.
The MoveEffect modifies position properties at each frame. This happens “immediately.”
Meanwhile, the ResizeEffect modifies size properties at each frame. This can cause positions to change (because my panel is vertically aligned middle within the application), but that doesn’t happen until the layout manager computes the new position.
The reason you see the jagged motion is that the contents get moved, and a frame or two later, the effects of the parent resize are displayed.
Short of changing Flex to have tighter guarantees on this sort of thing, the best solution is to not animate the positions of things that are inside containers that are being resized. Either let the layout engine figure out the positions of everything inside the container, or use MoveEffect to move something inside the container, but not both.
At some point, I want to experiment with creating a proxy object that floats above the container to see if I can create the illusion of having the label move smoothly as its container resizes. It’s probably a better way to go in any case, because this allows you to set start delays and easing functions for both the resize and the move without causing weird interactions between the two effects.
P.S. Let me know if you’ve tried something along these lines!
I don’t know if it’s just me, but I don’t get any animation in the linked file for this or the previous entry.
And I’m interested! I was fighting with effects a few months ago, and basically gave up and abandoned 80% of what I wanted to do. I could probably do a lot more now that I understand the languages better, but there were still a lot of things I didn’t understand. :-)
Bah, delete my last comment, I can see it now (d’oh).
I am frightened that your posts are from 2005 and I am running into exactly the same issues today. I think for as easy as MXML makes things, it also makes it easy to do things terribly wrong.
Any further insights on this subject?
Yeah, it’s a bummer. The short answer is that MXML was not really designed to handle this situation. Either you should (1) animate properties such as the width of a box and let the layout engine position the items inside, or (2) animate the items yourself, and also lay the objects out yourself. In cases where your animation is going to be somewhat complex, I would favor (2). Check out http://kuwamoto.org/2007/05/17/introducing-the-flexiblecontainer-component-aka-advanced-actionscript-refactoring-step-3/ for an example of how to handle your own layout.
Bah, delete my last comment, I can see it now