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.
Related
From the cobalt document of 360 video, cobalt implements it with CSS, it does not use webGL to implement it, so What’s the difference for the performance between CSS and webGL to implement 360 video? Is there any performance influence with the platform when play 360 video?
CSS Spherical Filter Extension for 360 is known to be better than WebGL 360 in terms of performance.
CSS implementation helps keep JavaScript out of the render thread and leave the 360 related calculations within the browser on a separate thread from the render thread.
WebGL requires JavaScript to render every single frame. It's not easy to guarantee that JavaScript runs quickly while handling other things such as inputs, XHR requests, and such. And that will bring a frame skip.
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.
I'm working on a client-side web app that is meant to run on an iPad 1.
Besides the fact, that the framework I'm using is slow-as-a-snail (not my choice), the app is making a lot of calls to the server. Right now i'm working on a "Loading..." screen. My question is:
Should I use CSS3 animations or simple GIF animations? Which one is faster?
In my experience on iPhones and iPod Touches (not iPads, but I take it they'll probably be about the same), GIFs are several orders of magnitude slower in animation than CSS animations, transitions, or what have you. I think their framerate is deliberately slowed, maybe to save battery life.
the app is making a lot of calls to the server
Using GIF animations would require another call to the server to fetch the image. If the implementation times are comparable, using CSS3 seems more appropriate; it would likely take fewer bytes, and ride along with your existing CSS file.
A more pragmatic answer is that it doesn't matter, for a simple animation the speed difference is negligable. And if your app already requires a loading screen, why worry about how long the loading screen takes to load?
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.
I'm planning on writing a game using javascript / canvas and I just had 1 question: What kind of performance considerations should I think about in regards to loading images vs just drawing using canvas' methods. Because my game will be using very simple geometry for the art (circles, squares, lines), either method will be easy to use. I also plan to implement a simple particle engine in the game, so I want to be able to draw lots of small objects without much of a performance hit.
Thoughts?
If you're drawing simple shapes with solid fills then drawing them procedurally is the best method for you.
If you're drawing more detailed entities with strokes, gradient fills and other performance sensitive make-up you'd be better off using image sprites. Generating graphics procedurally is not always efficient.
It is possible to get away with a mix of both. Draw graphical entities procedurally on the canvas once as your application starts up. After that you can reuse the same sprites by painting copies of them instead of generating the same drop-shadow, gradient and strokes repeatedly.
If you do choose to draw sprites you should read some of the tips and optimization techniques on this thread.
My personal suggestion is to just draw shapes. I've learned that if you're going to use images instead, then the more you use the slower things get, and the more likely you'll end up needing to do off-screen rendering.
This article discusses the subject and has several tests to benchmark the differences.
Conculsions
In brief — Canvas likes small size of canvas and DOM likes working with few elements (although DOM in Firefox is so slow that it's not always true).
And if you are planing to use particles I thought that you might want to take a look to Doodle-js.
Image loading out of the cache is faster than generating it / loading it from the original resource. But then you have to preload the images, so they get into the cache.
It really depends on the type of graphics you'll use, so I suggest you implement the easiest solution and solve the performance problems as they appear.
Generally I would expect copying a bitmap (drawing an image) to get faster compared to recreating it from primitives, as the complexity of the image gets higher.
That is drawing a couple of squares per scene should need about the same time using either method, but a complex image will be faster to copy from a bitmap.
As with most gaming considerations, you may want to look at what you need to do, and use a mixture of both.
For example, if you are using a background image, then loading the bitmap makes sense, especially if you will crop it to fit in the canvas, but if you are making something that is dynamic then you will need to using the drawing API.
If you target IE9 and FF4, for example, then on Windows you should get some good performance from drawing as they are taking advantage of the graphics card, but, for more general browsers you will want to perhaps look at using sprites, which will either be images you draw as part of the initialization and move, or load bitmapped images.
It would help to know what type of game you are looking at, how dynamic the graphics will need to be, how large the bitmapped images would be, what type of framerate you are hoping for.
The landscape is changing with each browser release. I suggest following the HTML5 Games initiative that Facebook has started, and the jsGameBench test suite. They cover a wide range of approaches from Canvas to DOM to CSS transforms, and their performance pros and cons.
http://developers.facebook.com/blog/post/454
http://developers.facebook.com/blog/archive
https://github.com/facebook/jsgamebench
If you are just drawing simple geometry objects you can also use divs. They can be circles, squares and lines in a few CSS lines, you can position them wherever you want and almost all browser support the styles (you may have some problems with mobile devices using Opera Mini or old Android Browser versions and, of course with IE7-) but there wouldn't be almost any performance hit.