I've been told several times or I've read in various places (can't remember where exactly right now) not to use Tween classes from the Flex SDK but to use instead other animation libraries like Tweener, TweenMax, GTween, ...
What's wrong with using Flex tweens? Is it a performance issue?
If I want to do states transitions, should I make custom transitions with third-party libs?
For reference, here are some helpful things:
Actionscript Tween Performance Comparison - Browser crashes when you use default Flex 3 Tween classes.
Mr. Doob's List of Actionscript Tween Libraries.
If your goal is just to do state transitions in skins, then it is easiest to use the Flex Effect classes. Flex 4 is about to be released and it has completely rewritten its Effect library, much faster than Flex 2/3. I ran a quick test with tweening 100 mx.controls.Button instances 500ms each, one after the next, using TweenMax and Flex Effects, and TweenMax was about twice as fast (meaning I could see 15 objects moving at once instead of 7 or 8). So if you can, I would do all animations with TweenMax. Definitely the most versatile/popular/modular/optimized. But for skins, and because Flex Effects are ready to use in skins in MXML, use them.
Also check out Tink's Efflex Flex Effect Library for some nice Container/Viewstack effects (some in 3D).
Depending on what blogs you've been reading they might have an emphises on flash/actionscript. In which case it might recommend something like tweenlight or similar.
If you are using flex and its libraries then there is no reason not to use the flex effects (which are based on flex's version of Tween). Note that the flex Tween is different than the flash Tween. But you don't really have to worry about that, if you wish to move something, just use the Move effect, if you wish to fade something then just use the Fade effect.
Some people may recommend another tween package because it makes the overall SWF size smaller, but it depends on how you are building the end SWF. Are you deploying the SWF with the flex framework as an RSL (recommended although Google can't search your SWF yet if you do this, check this link) then it would be best to use the Flex effects. If you're not using the framework as an RSL then it would be a case of test you app to see what version came out as the bigger SWF file.
I've never had any issues with performance using the flex effects.
Some of the 3rd party tweening packages do effects that are not part of the flex library, but other than that I can't think of any good reason not to use the flex effects/tweens.
Related
Famo.us claims that it "talks directly to the GPU" to compute themselfs the css transforms. I assume they are talking about the 4x4 transform matrix.
When they say the "talk to the GPU" it means they are doing their maths in WebGL?
When they show 3D elements are they using WebGL in a canvas element?
Is their technology real THAT special or their claims are the result of an excellent marketing campaign?
Disclaimer: I do not work for Famo.us, I just share their vision in way software should be built.
The answer to all three questions is no. When they say talks to the GPU, they are not referring to the matrix calculations, they are referring to the matrix3d property of CSS that is GPU accelerated by the browser. By throwing out the box model of normal HTML and CSS, we can create a new model that follows the likes of traditional graphics development, which is based on a Cartesian coordinate system and all elements are absolutely positioned with 3d transforms.
There is no WebGL and no write to canvas. Every one of the (surface) elements on screen is just a div that is transformed. Every bit of text will still be highlightable and every button will still be clickable. It's all live. The rendering starts at the Context, which in most cases is the top level of the render tree. Nodes for other subviews are added as children. On each render cycle the context's render function is called, which in return looks down the tree and calls the render function of each subview recursively. Since the render engine is tightly integrated with requestAnimationFrame, all calculations can be determined then rendered at the time of screen refresh.
The technology can be considered special, because it throws away so many traditional paradigms in favor of a more modern approach to building web applications. That being said, it's really only Javascript. HTML was not built for web applications. HTML and CSS were built for static content pages and work as a crutch in trying to achieve applications similar to the ones we love and adore on mobile. Famo.us makes it possible to build applications with only JS, or a compile-to-JS language like CoffeeScript. You define Surfaces which correspond to divs on screen, and you apply properties for HTML attributes and CSS. You still have the option to apply CSS classes or inject HTML into surfaces.
In the end the choice is up to you. If you do not see the value, or are comfortable with the way you build web applications, then stick with it. Over the next few months you will see many more demos popping up as real users like myself create them. I can tell you already, it's amazingly promising.
Cheers
I want to add a slightly updated answer:
(I, too, don't work for Famo.us, but I did spend three weeks there working on projects)
While #johntraver has summed up pretty nicely what Famo.us does at the moment, it is important to understand that famo.us WILL support canvas and webGL.
Going deeper into the philosophy of famo.us, it throws away all the tools that HTML and CSS provide for layout and animation. ALL surfaces in famo.us are absolutely positioned at top:0, left:0 and EVERYTHING else is done purely with transforms, that are calculated by famous.
Animations are also done in javascript and don't use CSS transitions or Animations.
The more you think about it, Famo.us has almost no dependency on HTML or CSS, and that is exactly the plan. Famo.us treats HTML as just one of many possible renderers.
They are now working on adding WebGL rendering to famo.us. Essentially, what this will enable is a common API for layout and animation that will be able to render to WebGL AND HTML for the best of both worlds.
So, calculations will still be done in Javascript entirely, but the output may either be surfaces with transforms OR WebGL.
Hope that helps.
I am trying to get my application looking somewhat decent and flex uses CSS so does that mean I can use bootstrap? I just don't know how I would implement it in the code once I have the CSS as mxml is different to html. If not, are there any other frameworks I can use to get my application looking better?
No; Bootstrap requires javascript (not available inside the Flex app). Also, Flex uses its own customized subset of CSS with some important differences from the spec.
I have a Flex application where some interactions cause many objects to require visual updates all at once. These updates translate into state changes for many MXML based components which have state based transitions. The transitions look great when just a handful of the components animate at the same time... but when all of them animate at once... the Flash Player just can't keep up.
Any ideas on how to create something of an animation pipeline so that everything can have a chance to keep up? Or maybe some other solution?
Did you try working with suspendBackgroundProcessing property of Effect or disableLayout property of Animate class descendants? You can define them on MXML animation definition nodes.
Personally, I try to stay away from the Adobe effects library as they're slow and not all that good. If you want animation 'groupings', consecutive animations, or even animation timelines, I would suggest you use TweenMax.
I was told that there is an increase in performance when using Canvas versus HBox or VBox when laying out out the position of children. As a result, a number of our components have been converted over to using Canvas. However, now there is code being added to calculate the x and y positioning of some of the child elements based off of the width and height of other children. Is it worth using a Canvas to increase performance if code needs to be added to determine the coordinates/positions of the children? Is there a better method or technique available that should be practiced other than just minimizing the number of ui components added and specifying positioning absolutely?
There are a number of middle-of-the-road techniques, one of which is to use rendering-type components, such as TileGrid or ItemRenderers, if your layout fits a certain formula. If you're using forms, try using the Form layout component instead of using a custom layout.
If you do need to use the layout engine in Flex, the way to optimize your usage is to remember that certain techniques are used by the framework in increasing performance load, loosely following the below list, the last being the most performance intensive:
absolute positioning (<Canvas>)
relative positioning (<VBox>)
constraint-based positioning (right=0)
advanced constraint-based positioning (<constraintColumns>)
Using relative positioning is usually not that performance intensive. If you are finding that it is, it could be that you're using too many nested containers. Look at your layout architecture and try to find out ways in which your objects may be "over-laid out", and simplify them. A good tool for this is FlexSpy, which lets you introspect object layout at runtime.
Another common performance bottleneck is that your application is attempting to do some number-crunching at the exact same time that your GUI is attempting to respond to user interaction. Although no green threading frameworks exist at the moment which enable you to run UI and logic in separate 'threads', you can use a good architectural framework such as Cairngorm or Mate (there are many) which uses Commands instead of straight up methods, so that functionality execution which may take up processing cycles waits until the UI has finished responding to the user.
A couple things you want to keep in mind while optimizing a Flex UI:
Avoiding excessive nesting of containers. Consider using a Canvas with absolute or constraint-based positioning over nesting lots of HBox / VBox elements. However this doesn't mean you should NEVER use VBox/HBox. You can mix and match, such as using a Canvas as the main container and positioning child Boxes inside them as needed, just try to avoid too much nesting.
Using the UIComponent model properly in custom components. In particular, using invalidateProperties(), invalidateSize() and invalidateDisplayList() so that their companion functions (commitProperties(), measure() and updateDisplayList()) are invoked at an optimal time for the Flash Player. Deepa gives a great talk about this here:
http://tv.adobe.com/#vi+f15384v1002
She explains how making heavy use of the invalidation scheme allows the Flash Player to execute your code at an ideal time, i.e. not in the middle of a screen update. These principles are used by all Flex components and can/should be leveraged regardless of the framework being used.
To make sure I understand:
You heard that Canvas can position children faster than [VH]Box
Canvas only does absolute positioning
Some (many?) of your components have an absolute position, so you switched to using Canvas
But some of your components have a relative position, so you need to write code to position them
Is that correct?
Anyway, assuming I'm correct (which may not be the case), the first thing you want to do is pick the functioning interface which requires the fewest lines of code, then decide if it's "good enough". You want the one with the fewest lines of code because studies have shown that there is a correlation between lines of code and number of bugs (and you don't want bugs). You want to see if it's "good enough" because, if it IS "good enough", you don't need to do anything (if you do try and make it faster, you're committing Premature Optimization).
But that's probably not what you wanted to hear :)
So I'll also suggest that, if you want to stick with Canvas-based layout, you try sticking all the relatively positioned content inside [VH]Boxes, which are then absolutely positioned inside the Canvas. There's a good chance the code Adobe has written is faster than code, so you should try to take advantage of it.
But the only way to know for sure is to try it and profile it.
Is there a preferred way to handle animation when using Flex -- For instance, if I want to render a ball and bounce it around the screen?
If you're building a Flex application, you should use Flex's native Effect classes. They're probably already compiled into your app, since the core components use them, and you won't increase your SWF size with duplicate functionality like you would if you used another library. For simple animations, either mx.effects.AnimateProperty or mx.effects.Tween should work well.
If you're working on a regular ActionScript project (without the Flex framework), then I concur with the answer given by Marc Hughes. However, if that's the case, then please don't say you're using Flex because that implies that you're using the Flex framework and it can be very confusing. If you mean Flex Builder, then please use the full name to avoid potential misunderstandings.
You can't always use Flex's effect class with plain sprites. Certain effects expect your target object (the object to be tweened) to implement IUIComponent interface, while others don't. So you can either use mx.effects.Tween, or if you must use the one of the effects classses, you will need to coerce your sprite into a UIComponent.
Another option is to use one of the tween packages suggested above or roll your own with goasap!
goasap
I prefer to use a tweening library for things like this. Check these out:
Tweener
TweenLite / TweenMax
KitchenSync
I've had good luck actually using the first two, and have read great things about the last one.
You can use mx.effects.AnimateProperty even though your target is not a UIComponent.
If the tween you want to acheive is a simple one (Move, Resize, Fade etc) this saves you writing the boiler plate code that mx.effects.Tween requires.