I'm a newbie in html5/CSS3/jquery, and I'm making this (not finished yet):
http://catherinearnould.sio4.net/autres/kat/
The problem is that, because of the large canvas with particles, the animations are not as fluid as it could.
So if you're bored, don't hesitate to have a look at my code and give me some advice to improve the fluidity ^^
Many thanks!
For one using RequestAnimationFrame() instead of setTimeout() is likely to make things smoother. See Paul Irish his blog post requestAnimationFrame for smart animating.
The big performance hits are most likely caused by live calculated/rendered CSS attributes such as transparency, shadows and rounded corners.
Also be aware of that changes to DOM elements which cause reflow is costly (such as animations), see http://code.google.com/speed/articles/reflow.html.
I see a big difference just after running this:
$('*').css({backgroundColor:'transparent', opacity:1, boxShadow:'none'});
If you can, replace all (semi-)transparent and rounded graphics with equivalent png images.
You could also think of using css3 transition for some of your animation and removing and adding new classes to the elements to changes their styles rather than doing it with javascript(jQuery). Use jQuery as a fallback for older-browsers and IE.
http://www.w3.org/TR/css3-transitions/
http://net.tutsplus.com/tutorials/html-css-techniques/css-fundametals-css-3-transitions/
This gives the browser the power to do the rendering, and in some cases like in the iOS you can get hardware accelerated for the rendering.
For the canvas element, I have little experience with that, but I'm interested in that effect you're creating. But I think the massive canvas animation at the start is a bit much, there is so much going on already, maybe there is no need for that effect? Just my opinion as a user.
Related
I develop a small application to test CSS3 and translate3d. The idea is to render several DIVs moving randomly on the screen. It's kind of particle system, I know I could probably use WebGL or Canvas to have better performances but I also want it to work smoothly on mobile browsers hence I thought that DOM manipulation would be better for performances.
You will find the result after a couple of hours at this url
I'd like to reach the best performance possible to increase the number of DIVs.
But here is my problem, I have a "rendering issue" that I spotted when I used TimeLine on Chrome or Safari. From time to time the whole page is rendered generating a small lag perceptible on Safari iPhone or Chrome Android+iPhone.
So if one of you one is up for the challenge don't hesitate I tried many things but I didn't figure out how to avoid this expensive redraw.
BTW, if one of you have extra ideas to optimize this snippets don't hesitate to reply.
Thanks
---------- UPDATE 1 ----------
Based on Ariya advices I updated by code (url) and added another test using only top/left.
Based on the FPS counter provided by Chrome I can see that the fps is more stable using top/left properties with almost the same framerate.
Do you have any idea if I could optimize the CSS3 version to have even better performances? I though that css3 with GPU Acceleration would be faster I probably did something wrong.
---------- UPDATE 2 ----------
I updated my code to use requestAnimFrame and only fire it when I need to redraw.
And I found what is killing the perf gray gradient background that I defined in the css was redraw often and killing the performance.
However top/left seems still better than CSS transition :( from a pure performance point of view.
When looking at the Timeline profile in Google Chrome's Developer Tools, it's evident that there is a lot of style recalculation. This is to be blamed at this particular line:
lastSheet.insertRule('#-webkit-keyframes '+keyframeName+' { ....
In other words, continuously changing the style sheet is expensive. Since the element animation in this example is about moving them around, rather than using keyframe-based animation I would recommend simplifying to simple transition.
For our website, we are developing a "component" that would display images in a similar fashion to Time Machine on Mac OS X. So it will be many images on top of each other, positioned slightly differently and with a smooth animation as you scroll forward and backward.
We have a spike implementation with CSS3 animations but it's not very smooth in Firefox and IE9 is not supported at all (though we may live with it if the other options are even worse).
We are considering implementation in SVG or Canvas but don't have much experience with it so I thought we'd ask first. So:
Requirements:
It must be fast. The animation must be smooth and that is a hard requirement.
It should be supported in as many browsers as possible.
Required browsers are Chrome 20+, Firefox 14+ and IE10+.
We would very much like to have support for IE9 too but can live without it if absolutely necessary.
Opera is nice to have but not necessary.
Options and our current experience / opinion on them:
CSS3 - seems like the "appropriate" technology for the task but unfortunately the implementation doesn't work so well. Maybe we have inefficiencies in our prototype code but the support seems quite different between different browsers at the moment.
SVG - at least it's vector graphics / DOM elements but we don't have any experience with it.
Canvas - we hope that it should perform well as it is used even for games but we can't quite imagine how would all the pixel redrawing work. Maybe we should use some libraries like processingjs?
Flash or other plugins - I happen to know Flash quite well and I know that the Time Machine-like effect would be quite an easy task there but we'd rather stay away from plugins at the moment.
Thanks for advice.
If the size of the component does not have to be very large, but can be limited to say around 800x600 pixels, then it sounds like Canvas should be up to the job.
If you only draw (scaled) bitmaps to the Canvas then performance is very good in my experience, even on iPad2. Performance only really starts to suffer at higher resolutions (1920x1080 and above), so if you use it for a fullscreen feature you need to watch out! Also, fancy features such as drop shadow etc. can slow down performance considerably as well.
Canvas has very few quirks between browsers, so it will almost certainly be less painful than using CSS3 or SVG in terms of getting it to work as expected across a wide range of browsers.
I would recommend whipping together a quick and dirty prototype with Canvas to see if it will meet your first requirement regarding performance.
If you decide to go with Canvas, I would definitely recommend using a library. Since you know Flash quite well you might want to take a look at EaselJS. It has a display list inspired by Flash, and the performance cost of using it is negligible in most cases. You also get basic events for interactivity. Also, if you go with EaselJS, it would be quite simple to port the code to Flash later if you decide to.
Are you looking for something like this? It uses SMIL animation so you'd have to integrate something like fakesmile to get IE support.
I'm implementing a HTML5 game using canvas. Now I'm thinking about making all text overlays like tooltips, speechbubbles, infowindows and so on using HTML elements with position absolute over the canvas. So I can use many effects and transitions CSS3 offers.
But I'm not sure about performance. These overlays have to be added and removed frecuently (is something MMORPG like, so there will be a lot of speechbubbles and so on).
There are probably 2 questions regarding performance:
DOM traversal to add/remove. Maybe a cache can help?
HTML and CSS3 itself.
The other option is to manage these elements in the canvas itself, drawing them each frame. But maybe I have then again a performance penalty, because of the extra code, timeouts and stuff I would have to add, to achieve similar effects like in CSS3. And traversal of some data structure would be needed anyways.
Any advices, opinions, experiences?
Thanks in advance.
Consider using only one of the mentioned two technology. May be you can release that application in mobile or tablet. I think on these devices would be issues with handling both the same time. And another thing: if you stay in canvas there would be no worries about compatibility. Its not a techy but a thought-provoking answer.
The single best reason for using the DOM for UI elements in HTML5 games is event handling.
If you draw everything on canvas you will need to write your own logic to handle clicks and decide what has been clicked on, which can soon become very complex, expecialy if you have multiple layers of interface.
With DOM elements (especially when using a library like jQuery) this is trivial, and you can create a rich and interactive UI with minimal effort.
The only downside I can think of is that you may encounter browser inconsistencies, especially if using CSS3, but again jQuery will help with this.
I suppose another downside is that once you go down the DOM route, your game is always going to be a browser game, whereas if it was 100% canvas, there would always be the possibility of porting the code to another language and making it native, but I guess that would only be a downside for some people.
One way to approach this is to use a "dynamic" image map behind your canvas object. Then you can use the dom as required. Note you will need to pass the clicks on the canvas through to the image map.
I have an idea in my mind for a simple technical demo. It will have a good amount, maybe up to 100, different text labels with varying rotations and Z-orders. Also, there will be constant animation so the size, rotation and position of the labels will change.
This could be done using CSS3 or Canvas as far I can tell. The CSS3 approach should be more accessible but are there any other real differences to consider?
Edit: I also need be able to place labels quite accurately with their centre point.
Either should be fine. I'd start with making a CSS3 one and then make a Canvas one only if somehow unsatisfied. Some considerations:
As of today text in the DOM looks a lot better than text on Canvas for a lot of browsers. Some browsers don't do subpixel rendering on Canvas text (While others do) making it something written in the same font in the DOM and in canvas look very different. For visual consistency, CSS3 is better right now.
Ask yourself what you might want to do with this later, if anything. Turn it highly interactive? Increase the number of objects above 10,000? Then you'll want to do Canvas, in short because 10,000 DOM objects is a "bad thing".
I'm not sure which one would be faster with merely 100 text labels. It shouldn't be hard to write up a quick test on your target platforms to see.
The CSS one will probably be much faster to make.
Canvas text gradients don't work on all mobile devices last I checked
Canvas text rotation + scaling used to look AWFUL in Chrome and Opera. Chrome has it fixed since version 12, Opera still looks awful. You can check your target browsers here: http://simonsarris.com/misc/scaleText.html Opera sort of looks like this.
while css3 would be the nicest solution, you should at least consider svg too.
see a live example : http://jsfiddle.net/gion_13/DhqEN/show/
p.s. : a big minus for canvas, because it does not have text selection
I have a design I'm creating in CSS, and it has started to sort of, er, lazy scroll. By that I mean the scrollbar lags a bit when you are scrolling. What are common causes of this so that I can debug it from my site?
EDIT:
The document has very little content (not even a paragraph), so not much at all. No flash, two images.
EDIT:
I feel so stupid. Improperly formatted background: property was causing the issue. Thanks nonetheless, everyone.
It's likely to be due to heavy processing requirements via css.
(CSS does affect scrolling in every browser) I have seen this scenario many times (the worst case is with SVG). It usually hits browsers like Chrome hard because of it's AA.
There was a great website that detailed the heaviest to the safest properties to use in regards to CSS effects, sorry I don't have the link. Though from my experience I would say to consider:
Gradients: The more you feature or the larger the area they cover the more exponential the rendering calculations. Abusing stops and additional colors also adds to the mayhem.
Border-Radius: Is usually clipping off its internal content whatever it may be. I've noticed differences when excluded.
Opacity can be the main issue if coupled with other css effects. In certain scenarios I've found great improvements when removing opacity or reducing it's usage. As it's not just transparency it's driving it's also for some browsers anti-aliasing text.
Images: The way images can affect scrolling should be obvious, though I've discovered re-sizing imaged from it's native resolution can become a more noticeable factor.
Use of properties such as background-size:; draws huge power in certain situations, a workaround could be to scrap the div, replace with < img > and overlay with a blank div
containing text/ content.
Animations transitions & translations are obvious power eaters if abused, especially animation that loops continuously or re-sizes to the browser via percentages.
Bare in mind someone on a low spec celeron PC will have a terrible experience on a site that lags on your reasonably/ high powered PC/ mac