GSAP claims to use HTML5 to perform outstanding animations for web use, but says clearly in the their article on Greensock.com that it does not use the canvas frame work in html5. It is clear that they are using Javascript from the provided script, but it is very confusing to interpret. In what other way would they use html5 animations without the canvas? And if they do use pure HTML5 does this mean that HTML5 animations are significantly faster than CSS, jQuery, and Javascript?
There's not such thing as "html5 animations".
There are, mainly, CSS3 animations (with either CSS transition or CSS animations) and Javascript animations.
CSS3 animations are generally well optimised (with a few quirks) but lacks support (old IEs) and flexibility (you'll have to use JavaScript to tweak them.) They're best for hover effect (with transitions) or basic animations.
JavaScript transition used to be based on a setInterval. A timed loop, and inside this loop the styles are changed. JQuery does this, and not very well.
Recently, Window.requestAnimationFrame() was introduced to replace these setInterval animations. Support is limited (old IEs), performance is top notch (because the browser can skip frames), and it's always style updates inside.
What GSAP does is using this requestAnimationFrame() while optimizing for less repaints and adding a lot of useful features (reverse, timelines, stagger...) On basic animations, you can achieve the same performances with CSS3 or your own JS code... if you know what to do.
There are also others animations (canvas, svg... event webgl) but more specialized.
In my limited experience with GSAP, and during some discussion with the developer of Velocity.js, it seems that GSAP has some very convoluted code that is quite difficult to interpret; I'm not sure if this is because they're purposefully obfuscating the code or that they do some very crazy optimizations... Maybe a bit of both. They may have also taken native code and created a Javascript implementation. In any case it makes reading the source quite difficult to do.
As far as your question about HTML5 animation, which I'm taking to mean animating objects on the DOM without Javascript, if you're using a compliant browser, you can achieve many animations via the CSS transform and transition property, the former being about DOM object transformations (moving it 10px to the left) and the latter being about how the object moves as it transforms (does it move linearly over a period of time, or use a user specified cubic bezier curve to describe its motion?). With current compliant browsers, the main difference in these properties besides vendor prefixes like -webkit- and -moz- is small. What this means is that you can reliably get animations on DOM objects across those browsers if you take case of the prefixes. You can use these transform/transition properties to manipulate almost any DOM object property.
In terms of speed, it depends. CSS animation is generally the faster between it and Javascript, but it lacks control because it's hard/impossible to manipulate certain properties like key frames. Javascript animation is slower, but using a good library makes this difference negligible and in some cases Javascript animation can be faster. It really depends on what you're trying to achieve. CSS and newer Javascript library animation is considerably faster than jQuery due to some reasons listed here.
*: Of course some browsers, like IE9 and 10, while being relatively compliant, do miss some properties and have quirks about their rendering engines.
Related
I've been wondering for some time now why should I use Angular animations over CSS animations. I see few areas one might consider before using them:
Performance
In the first step I found this question which deals only with performace side of things. The accepted answer is not satisfying for me because it states that one should use CSS animations wherever possible so that optimizations like running the animations in separate thread can apply. This doesn't seem to be true, because Angular documentation states
Angular animations are built on top of the standard Web Animations API and run natively on browsers that support it.
(emphasis mine)
And when we look at Web Animations API Draft we see that the same optimizations can apply to Web Animations as to CSS specified in sheets.
While it is possible to use ECMAScript to perform animation using requestAnimationFrame [HTML], such animations behave differently to declarative animation in terms of how they are represented in the CSS cascade and the performance optimizations that are possible such as performing the animation on a separate thread. Using the Web Animations programming interface, it is possible to create animations from script that have the same behavior and performance characteristics as declarative animations.
(emphasis mine again)
Apart from some browsers like IE don't support Web Animations, is there any reason to use either CSS declarations over Angular animations or vice versa? I see them as exchangeable performace-wise.
More control over the animations
This might look as an argument for Angular animations, because you can pause animation or use JS variables with it etc., but the same is true while using eg. CSS animation-play-state: pause or using CSS variables specified in JS, see documentation.
Now I can see it might be inconvenient to set the CSS variables in JS code, but the same is true while using Angular animations. These are typically declared in #Component animations field and don't have, except for via the animation state data bound property, access to instance fields (if you don't create your animation via AnimationBuilder of course, which btw is also not very convenient or beautiful either).
Other point is, with Web Animations API it is possible to inspect, debug or test the animations, but I don't see how this is possible with Angular animations. If it is, could you please show me how? If it isn't, I really don't see any advantage of using Angular animations over CSS ones for the sake of control either.
Cleaner code
I've read for example here a paragraph stating that separating animations from "normal" styles is actually separation of behaviour and presentation. Is really declaring animations in styles sheets mixing those responsibilities? I saw that always the other way, especially looking at CSS rules in the #Component animations gave me a feeling of having CSS declarations on one too many places.
So how is it with Angular animations?
Is it just a convenience utility to extract animations away from the rest of the styles, or does it bring anything worthy feature-wise?
Does a usage of Angular animations pay off only in special cases or is it a convention a team chooses to go all the way with it?
I would love to here about tangible advantages of using Angular animations. Thanks guys upfront!
So I did some research and although I didn't find any argument for nor against Angular animations performance-wise (as already stated in the question above), there are very good arguments to use Angular animations feature-wise which should be good enough for purists who want to have CSS only in sheets, at least in certain cases.
Let me list some useful features where each alone makes a convincing case for Angular animations. Most of them can be found in Angular animations documentation:
Transition styles - these styles are only applied during transition from one state to another - only while an element is being animated, and one uses them like this:
transition('stateA => stateB', [style({...}), animate(100)])
Trying to do the same with CSS only might not be as expressive in terms of which previous state led to the next. And it can be outright clunky if the animation has to differ based on the initial state but the end state is the same.
The void state together with :enter and :leave aliases (void documentation, :leave and :enter documentation) - Let you animate elements being added or removed from the DOM.
transition('stateA => void', animate(...))
This is very cool because previously, although it was easy enough to animate the addition, the removal was more complicated and required to trigger animation, wait till its end and only after that remove the element from the DOM, all with JS.
Automatic property calculation '*' (documentation) - Allows for performing traditionally difficult animations like height transitions for elements with dynamic height. This problem required either to set fixed height on element (inflexible), use max-height with tuned transition function (not perfect) or query element's height with JS (potentially causing unnecessary reflows). But now with Angular it is as easy as this:
trigger('collapsible', [
state('expanded', style({ height: '*' })),
state('collapsed', style({ height: '0' })),
transition('expanded <=> collapsed', animate(100))
])
And the animation is smooth and "complete" because the actual height of the element is used for the transition.
Animation callbacks (documentation) - this is something that wasn't possible with CSS animations (if not maybe emulated with setTimeout) and is handy eg. for debugging.
Unlike stated in the question, it is actually possible to use instance fields as params in Angular animations, see this question. I find it much easier to use than manipulating CSS variables through DOM API as shown here on MDN, not mentioning the limited support in some browsers.
If you need any of the features listed above, Angular can be a better tool for the task. Also when there is many animations to manage in a component, and this is just my personal opinion, I find it easier to organize animations the Angular way than have them in sheets, where it is harder too see the relationships between them and various element states.
To animate an element, we can use css animations, or we can do it in javascript.
Reading up on this, it seems like css animations are expected to render more quickly than javascript animations, since the browser can execute css animations in native code. This info was gathered from posts dated from 2008 - 2011.
With ios 6, is this still the case? In the release notes, I found this item:
"WebKit no longer always creates hardware-accelerated layers
for elements with the -webkit-transform: preserve-3d option.
Authors should stop using this option as a way to get hardware
acceleration."
http://developer.apple.com/library/ios/#releasenotes/General/RN-iOSSDK-6_0/_index.html
Since I'm pretty new to animations in the web, I'm not sure what the current status is,
Thanks
CSS animations and transitions will always be faster than JavaScript ones, simply because there is just a single instruction to be handled, as opposed to having to follow all the JS instructions required for the same effect.
I'd interpret the release message as "It is no longer guaranteed that a value of preserve-3d enforces hardware acceleration" (and should not be used as a hack to assert HA). If the UA chooses not to use HA, it will have good reasons for that.
Regardless, native implemented CSS transitions are still faster than manual JS animations (in general, at least). Also, there is no cause for using JavaScript when you can achieve the same thing with short [basic] CSS.
I'm working on my new portfolio and I want to use a complex javascript (for animating, moving, effecting dom elements) and i going to do as much as possible optimization to maximize the performance. BUT I can't prepare for all the case with my site will be faced. So i started to looking for a script with I can check the browser performance (maximum in a few seconds) and based on the performance test results I can set the number of displayed and calculated effects on the page.
So is there any way to check browser performance and set the optimal number of applied effect on a page?
If possible, use CSS transforms/transitions instead of pure-js effects, as the former are usually hardware accelerated and thus orders of magnitude faster.
Even if you don't use CSS transforms, you can detect support for them using e.g. modernizr, and if supported, you can assume that the browser is very modern and has pretty good performance in general. Take a look at window.requestAnimationFrame, it automatically throttles the framerate.
I'm a long-time Flash developer who's recently decided to dive into HTML-based web apps, since, in my opinion, HTML5 provides a really compelling alternative to Flash.
(Not in every case - each technology has it's strengths and weaknesses - but HTML5 has a lot going for it).
Anyway - I can't speak for anyone else - but any time I dig into a new technology/language - I need to get my head around some core concepts.
One of the notions for me that's starting to gel is that divs in HTML are reasonably equivalent to movie clips (or sprites) in Flash.
In other words - wherever i'd use a movieclip/sprite in Flash - I'm now using a div.
Two key points of clarification:
I'm specifically ignoring the timeline concept, since I never used that in Flash anyway. In my mind, movie clips/sprites are just "objects" with visual properties that I could manipulate with code
I'm tending to use absolute positioning with divs, since A) that's how I thought of things in Flash (x, y, and z, coordinates), and B) with web apps, the UI elements of app "screens" tend to have fixed positions, and don't "flow" with variable-length content
So - my question, for those who consider themselves reasonably expert with both HTML and Flash...
Is this a useful/accurate comparison?
Or, do I have have an incorrect understanding of how divs should be used?
What fundamental ways are they different?
What trouble am I likely to get into based on this assumption?
Many thanks in advance!
Yes, in most cases you will be using div in HTML, where you would use a MovieClip (or Sprite) in Actionscript. Here are a couple of situations where a div alone won't be enough:
divs do not have the EnterFrame event. You'll need timers to emulate that, or some sort of animation library (jQuery's .animate() should do the job in most cases).
If you use methods from the AS3 Graphics class (as in mc.graphics.beginFill(0xff0000)), you'll may need to use HTML5 canvas instead. For example, if you need a circle, you can either use canvas, or use an image instead.
Also, you'll have to keep your eyes open for browser support limitations on many HTML5/CSS3 features. For example, rotating a MC in AS is a no-brainer, but in HTML5 it's not supported in all browsers.
I know this is not a complete answer, but I hope it helps!
I haven't used Flash in years so I may not be the best person to answer but you seem to have the grasp of what a div is. You did note that you use a lot (all?) absolute positioning. I would recommend you not to this unless you are looking do animate the DIV in some way.
You can get a lot of benefit from using relatively positioned divs or a combination or relative and absolute.
I'm wondering what the most viable approaches are for 2d game graphics, running in straight (and cross-browser) Javascript?
I've found the canvas and SVG approaches so far. Are there other straightforward methods that offer primitive graphics operations like drawing lines, circles, pixels? Preferrably supported out of the box in IE, unlike canvas/svg. :)
(I recently wrote a dinky little javascript game. Straight CSS+DOM worked for me in that case, but I'm looking into better ways of doing it next time.)
-ThomasN
You can have a look at this very simple library:
http://fx.inetcat.com/
Quoting their manual:
Compact lightweight JavaScript library
which extends DOM element by adding
animation methods. Facilitates CSS
properties and other parameters
alteration along timeline. Supports
parallel effects sets and effects
chains. Has extended set of callbacks
to adjust behavior.
If you follow the manual you see how easy is to make animations.
I'm just starting my JS port of a game I'd written in Silverlight, so I haven't used it (yet), but I was really impressed by the demos and API for Raphael.
It has a great set of functions, including awesome animations.
An svg-based library lends itself well to developing with physics engines and such, in addition to being able to animate and manipulate (rotate, mirror, etc.) images/sprites.