Rethinking Flex Animations: [Bindable] causing intense application lag

Question

Hey,
There is a big difference in animation/effect performance across computers in Flex.  On our macs (Mac Pro desktop, Macbook Pro, MacBook), everything is fairly smooth (Firefox and Safari).  On any Windows XP (Firefox or IE), alpha and translation animations/effects are very choppy, not to mention rotation or anything more complex: a TweenMax alpha tween from 1 to 0 in 1 second only uses 3-4 frames, instead of 24-60.  On Windows Vista, it's like 2 frames (this is on a Panel 500 x 500).  Same with tweening x and y.  Same with running Andrew Trice's KeyFrame and MotionPath example, very choppy on anything but a mac, especially if you have a full blown application with 50+ components on the stage at once.
I think this might have something to do with the event dispatching going on with animating properties.  When you tween the "alpha" on a UIComponent for 1 second, it can dispatch more than 20 "alphaChanged" events, even when there are no listeners for it.  Add in a position animation, and you easily have 50+ events being dispatched for every item animating on the screen, plus calls to invalidateProperties(), invalidateDisplayList(), etc. (setting UIComponent.suspendBackgroundProcessing to 'true' doesn't help), plus all the background binding execution flex generates in the background.  Tons of things pure Actionscript doesn't use when animating.
In pure Flash/Actionscript, when you do animations (like those found on Template Monster website templates), they are VERY smooth, even on Windows Vista.  The only difference between these animations and those in Flex is:
1) Flash is not dispatching any events when properties change.
2) Flash is not calling any invalidation methods when properties change.
Granted, invalidation and binding is core to Flex and I love it dearly.  But if there was/is a way to prevent any binding updates (event dispatching), and calls to even any invalidation methods WHILE ANIMATIONS ARE RUNNING, I think animations in Flex would be just as smooth as those in Flash and pure Actionscript, on all computers.
Question is, is this possible?  Is it possible to say "don't update any bindings on these objects until this animation is complete"?  If not, is Ely or others involved in the new Spark architecture willing to take on such a task?  Otherwise it's pointless to use anything but the simplest animations (changing alpha or color on a 20x20 ButtonSkin) because its choppiness will just detract from the User Experience.
Thanks for your help.
Lance

Answer 1

Hi Lance,
I know you're asking about performance of non-Flex tweening engines, but I'll answer from my Flex 4 effects perspective, since that's what I know. All of the tweening engines, including Flex 4 effects, use a similar approach, however; they just animate the properties of Flex objects. So they would all share similar performance characteristics in general.
The performance of the animations is highly dependent on what's happening in your application. I'm surprised you're seeing as little as 2-4 frames per second, but I would bet there's a lot happening in your app at that time, because it's not hard to achieve much higher frame rates (like 30-60 fps) in very simple situations.
Data binding and layout could be contributing to the performance. I'm not sure how much data binding itself adds (just sending out the events when properties change), but it may be what the listeners are doing with that information that is bogging it down. That is, maybe sending out the event for alpha changing doesn't cost that much, but the listeners may be doing some processing on that change, or any change in general, that is coming at a cost to the system.
There is no flag to disable binding events that I know of. There is a property on Flex effects that disables some event processing (suspendBackgroundProcessing), but it's a bit of a heavy hammer and I wouldn't recommend it as a general approach. (In fact, I'd like to ditch that property since it has some odd consequences at times).
Layout will also contribute to the problem, depending on what's happening. For example, if you are resizing a button in a vertical layout, then the layout will want to shift around the sibling objects to adjust to the size change. That is probably what you want to happen in the UI, but it comes at a cost since the layout has to recalculate everything for the container on every animation update.
There is a flag in Flex effects to reduce the processing of layout in particular: disableLayout=true. This tells Flex to avoid doing layout on the target object's container during the course of the effect. Again, it's a heavy tool to wield, but can be the right thing to do in some situations.
There might be a better general approach we could look into eventually, such as running animations that are more visual than functional (e.g., resizing a button's graphical assets without sending out events as the button changes), but that'll have to come after this release, in which we were focusing on getting the architecture right for spark and flex 4 effects.
In the meantime, I'd play with a profiler and see where you're getting bogged down with your animations; I've seen some pretty slick stuff in non-trival UIs, so the fact that you're seeing such low frame rates means there might be something going on in your app that you could fix rather than waiting for us to think about how to lighten the load for animations.
For example, if you're seeing poor performance for doing a cross-fade between one screen and another, fading out all of the current components and fading in the new components, consider fading alpha on just the container itself. Or using the new CrossFade effect. Once you know more about where your performance issues are coming from, it's easier to figure out how to fix or workaround them in your application.
Chet.