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.
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.
Since I new with CSS, I just started to work with CSS Grid system. I would like to know if are there any technical issues in use CSS grids? I mean, which are the reasons for you to not use grid?
Thanks
Flexibility
Once you start using the grid, you are stuck with it. Any other issues you might wind up finding you will have to conform to.
In my opinion (and every other designer I've talked to) it is far easier to simply define your own columns and default sizes as classes and apply them as-needed. A custom grid if you will. Then changing the styling is as easy as changing a line or two of CSS, instead of either re-generating the grid system or redesigning the site and sacrificing in order to use the grid.
I'm a fan resets and some minor love from Blueprint (especially the Typography), but that's about it.
I've just started using object oriented CSS (OOCSS). I'm really enjoying it because it provides a very basic and minimalistic grid system. It allows you to create relative sized grids by dividing an element into halves, thirds, fourths, or fifths. The divided elements are infinitely nestable.
OOCSS is more of a philosophy than a framework. It's all about how you extend a very basic foundation.
Check out these links:
http://oocss.org/
http://developer.yahoo.net/blogs/theater/archives/2009/03/website_and_webapp_performance.html
http://www.youtube.com/watch?v=j6sAm7CLoCQ
The only real reason is that they can lead to bloated markup, sometimes you have to do some serious nesting depending on the layout and desired effects+flexibilty.
They also lead to excessive class name lists on elements. However, you can avoid this at least if you move the CSS to semantic classes/ids before deploying... but thats can be alot of extra work. Blueprint is the excpetion here because it has acommand line tool to allow you to apply the rules from its framework classes to semantic selectors.
Overall i generally use them because its alot easier to teach a designer how to use a grid template. That why im not do alot of production art tasks when i go to slice things down. It jsut makes the whole process smoother IMO.
If your site has a column layout AND repeatable design patterns throughout the site... then there aren't any reasons not to include a grid. A grid adds: organization, proportion and alignment to your page. So why not keep that consistent? There is no reason.
Just don't Overuse A Grid
Some people say a grid is inflexible? That's not totally true - you can use it where you need it. You can always remove it or adjust. Just don't overuse it.
It depends on the grid system. Most grids have a fixed amount of columns, which restrict you in how you create your layout. For example, they don't allow you to combine 30%/30%/40%, 50%/50%, 25%/75% and whatever other combinations you can think of.
Some grid systems also don't allow nesting. That means you can't use a grid element as a grid for child elements in those grid systems, which makes it a lot more difficult for many layouts to be coded to HTML.
Also, some grid systems use techniques that don't work in older browsers. Before you use a grid system, you should always make sure it supports the browsers you need to support with your project.
There are frameworks out there without such restrictions, though. Cascade Framework, in fact, has a grid system far more flexible than that of any other framework out there and works fine in both IE6-8 and modern browsers alike.
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.
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.