How to measure the performance of CSS transitions and animations - html5-canvas

I want to compare the performance of jQuery's animate function and pure CSS3 transitions. I've found out that there is a requestAnimationFrame API to measure the performance but it seems that it can only be used with the canvas element?
Is there a good way to test the performance of absolute positioning compared to CSS3 and canvas?
Is stats.js helpful and trustworthy? What are your experiences?
I built this jsPerf test. Unfortunately the jQuery.on method is not executed. :(

I would argue that transitions/animation rules should be in the CSS as they are a presentational element, and JavaScript is meant for behaviour. For this reason I would stick with CSS transitions and leave JavaScript to do form validation/ajax/etc. But that doesn't mean that JavaScript is a wrong technology to use for animation, the very nature of the web being that you can use technologies in a variety of ways, because there is a lot of overlap between them.
I have a few links for you that I think you might find useful; Paul Irish/Chris Coyier's discussion over translate, a video on animations in CSS transitions vs Javascript and this link showing the framerate comparison between jQuery and CSS. You can see in the third link that the CSS is definitely faster and smoother than the JavaScript; I'm guessing because it is hardware accelerated.
Couple of stackoverflow questions that conclude similarly: what's faster? CSS3 transitions or jQuery animations? :: Performance of CSS Transitions vs. JS animation packages
You're right in that the requestAnimationFrame function is only available for the canvas element. I would recommend using that if you are planning to sync CSS transitions with canvas output, as that is what it is built for, rather than going with setInterval.

Related

Drawbacks of CSS3 animation of SVG objects?

So I'm just getting into SVG and learning how it works. At the moment I am creating a project that involves rotating several SVG <circle>s at different speeds, thus learning how animateTransform works.
However, I found out that one can use CSS3 animations (which I am much more familiar with) on SVG objects. I realize that animateTransform can do more complex animations, but I'm talking in terms of a simple animation that both options have the capability of completing.
What are the drawbacks (if any) of CSS3 animations used on SVG objects when compared to animateTransform? Does animateTransform perform better?
No IE support for <animate… you have to use a polyfill library like fakeSMIL - which is not the end of the world. Also css3 transforms are GPU accelerated on iOS mobile and chrome for mobile (for the most part) so they tend to be smoother.

What is the fastest way of animating multiple sprites under html5?

I'm trying to animate 50 or so sprites at the same time, using a setInterval of 30ms.
What gives bettter performance?
Using canvas? Or using -webkit-transform and divs? Does anyone have any tips on making animations for html5?
The short answer to your question is that Canvas should give better performance.
This post from Facebook engineering should also be helpful in your understanding of Canvas speeds:
http://www.facebook.com/notes/facebook-engineering/html5-games-01-speedy-sprites/491691753919
Using Javascript and HTML5 canvas will give less headache than -webkit-transform and divs when you need to make changes to the animation.
I personally recommend HTML5 canvas and Javascript for compatibility (for now), since -webkit-transform is only available on Webkit browsers.
Sticking to the rule that human eyes cannot see frame changes beyond the speed of 20 frames per second (FPS), A setInterval() timer of 0.05s (aka 50ms) would probably be the best.
I follow how XNA game framework works, so I usually have 2 setInterval() calls, 1 to do the logic updates, and the other to draw the canvas.

Should I use HTML5 Canvas or CSS3 Sprites to animate objects for a game?

I'm in the process of starting to build a strategy game (think warcraft) for the web. I've been doing research on HTML5 Canvas and CSS3 sprites and still can't decide which technology to use.
The game won't be completed for another 6 months.
Any advice would be appreciated.
As you probably hear so frequently... "It Depends..." ™
My suggestion would be consider the feel of the application you're after. If you are trying to build a very graphically rich, mostly-images application, then I would use Canvas. However if you are trying to animate some graphics, but have the page remain and behave more "Web-like", mixed with other HTML content, I'd give CSS3 a try.
Two additional points:
Currently, Canvas is better supported than CSS3 animation/sprites.
If you use Canvas you're going to be implementing your own render loop and animation code (or making use of a 3rd partly library). Your code create animation by compositing the various layers of each frame, applying movement, and repeating. You can't simply say "move this image a little to the right". You'll have to do that yourself.
The EA web game "Lords of Ultima", as dull as it is, is an excellent example of a WarCraft-styled (well, it's more city building as there are no visible units) overworld, with animations and everything, built on a pure HTML and CSS sprite base. It looks and performs well and I think the square block box-model nature of HTML suits that kind of tile based design, especially since a lot of the image processing (embed an <img> or a <div> with a background, change background-position for animation) and click/mouse handling is done for you in simple html.
If you do go canvas you have to manage that yourself which will greatly increase the complexity and dev time. You'll have more control of minor elements and improved performance, but then you'll also lose (if it's at all important), greater backwards compatibility with older browsers. So it depends on how complex your design is and what kind of performance you need.
Use Canvas. If you use CSS sprites to build a game, then you are going to make a lots of <div>'s which performs operations on the DOM, which may slow down and also have a lots of focus and compatibility problems.
It may pay off to trade the development time for performance on <canvas>, by the assumption of "A code will be maintained forever".
I think CSS3 sprite system takes more time to develop, because you need to handle browser compatibility.
Browsers like IE 8 (8 or 9?) are using GPU to accelerate graphics, which lets you get the free lunch of Moore's Law.
There's pros and cons to both. Currently, Canvas is better supported then is CSS3, but you said that your game won't be done for another 6 months, by then the support for CSS3 could be much much better. There's also a lot of other variables here, such as: What browser will the game be viewed on? How advanced are the graphics you need to animate? etc... I would say that canvas would be better for support of the current generation of browsers and for gaming graphics, however CSS3 would be quicker, but wouldn't even come close to the support or graphics handling. But it doesn't seem like your in a rush to get it done.
Basically:
Canvas: Graphics, current support in users browser
CSS3: Speed of development
Ether will work. But for now I would use Canvas. However, 6 months in the tech world is an eternity, things could be a lot different then.

Browser Repaint/Reflow performance: using CSS3 Gradients vs PNG Gradients

I am working at an app that causes lots of browser reflows. Performance is a key issue here. From the performance point of view Is it better to use a CSS3 gradient or an image gradient for some DOM elements? Does a page that uses CSS text shadows and gradients will have a slower reflow as a page that uses images to achieve those visual effects?
Also, are there any reflow tests out there I can use?
For drawing, CSS gradients and shadows do task the CPU more than images. Performance used to be pretty bad, these days they are acceptable. If you have a ton of gradients/shadows, you should just implement them and do the tests in your real-world setting. If you just have a few, I wouldn't worry about it.
It depends a lot on how the browser renders it, but for the most part those things will render slower. In addition, you'll have a less pixel-perfect display in older browsers. However, this also serves to segment your audience, as generally those with updated browsers also have updated computers. So, it's a trade-off that can work in your favor to essentially serve a stripped down version of your site to those that wouldn't be able to handle it. It's not guaranteed, but I've found it usually balances out pretty well.
Overall, real-world testing is the way to go. Build it, see if it works, and fix performance issues once you find them. I wouldn't hesitate just because there's a chance it might not work. If it works just fine and you don't try it, you'll never know!

CSS - Optimizing rounded corners for speed

I'm trying to optimize my site for speed. I used images for the rounded corners before but now I've changed them with border-radius and -moz-border-radius css rules. Which way is the best for speed? I used to think that css rules are faster but I've seen a lot of sites talking about css sprites and I'm a bit confused now. Oh and I don't care about IE compatibility so you can suggest any method you want.
The speed goes like this: CSS > sprites > separate images.
The sprites is when instead of having separate images for the corners you use a single image and slice/position it with CSS. It's fatser, because you only download one image then. CSS is the fastest, because it doesn't need to download anything.
For those browsers that support radius CSS properties, use those. They are definitely faster, because no image needs to be loaded and they can be rendered by the browser's native engine.
For those (older) browsers that don't, apply an image-based workaround.
Don't worry too much about this stuff, though. The speed improvements reachable through optimizations in this area are very, very minuscule.
Both are exactly the same, except that because CSS3 specifications has yet to be finalized, Mozilla implemented border-radius with the -moz- vendor prefix. You'll need that, and the -webkit- version for rounded corners to function on Webkit (Chrome, Safari) and Mozilla (Firefox) browsers.
As for speed.. it is unclear whether you are talking about transfer or rendering speed. In either case I would suggest that the difference is negligible, and you should use all three for maximum browser support (minus IE, of course)
I would recommend CSS Sprites. This is a good tutorial: http://bavotasan.com/tutorials/simple-rounded-corners-with-a-css-sprite/

Resources