Javascript Speed - Chrome v Firefox

I wrote this small game at http://amarnus.me/games/dodge. Now if you trying playing the game in both Firefox and Chrome, you would clearly notice that it is significantly slower in Firefox. You can call it an unintentional cheat code, yes. ;-)

So my question is - Is this because of a slower Javascript engine in Firefox when compared to Chrome's? Or does it have somethi开发者_Python百科ng to do with bad coding? (In my defence, I am a Javascript newb)

Assuming that it is the former, then is this not a point against (disadvantage of) HTML5 games? (The ones using the <canvas> tag like mine)

Firefox is slower than chrome in javascript. However, I believe that it's also slower using the canvas-tag. This will probably improve with ff4 (have you tried the beta?).

There is also a nes emulator out on the web somewhere using js and canvas, and it runs in about 30fps on chrome (if I remember about correctly), but only about 10 in ff.

Time is probably your best friend :-P, though you can alwasy try to optimize.

I believe that browser-games will come in time, but it's not ready as of yet to anything too advanced. Maybe about the time ie12 comes out :-P.

[Edit] Btw: I tried the game in FF4b1, and I thought it ran great. Probably not as fast as in chrome, but not far from it :).

In order to get help you might consider providing a non-minified version of your script.

I see that there are 8ms setIntervals in your code. As mentioned above, Firefox never goes below 10 ms (yet). Playing your game in FFox 4 it is very enjoyable, though. I saw two very small hickups that clearly were caused by garbage collection. Chrome has an edge over the Fox in that regard. Even though SpiderMonkey (that handles GC in Firefox) has improved dramatically from 3.5 to 3.6 it's still not good enough for many games. In 4.0 it is a lot better, but still not quite as good as in Chrome or Opera. (It is being worked on.)

Playing the game and looking briefly at your code, I see no complexity that would cause Firefox not to be able to handle what's going on. Also Firefox 4 has hardware accelerated Canvas that is marginally faster than IE9 and a lot faster than Chrome.

There is a notion on the web that Chrome is faster than Gecko when it comes to canvas, but that is because people rarely profile their pages. In fact, canvas in Firefox 3.6 is already at least as fast as in Chrome, but many tests don't show it since the JavaScript is slower. (And some JavaScript tests are slower because Firefox does not handle the test harness well.)

All this leads to lots of confusion and misinformation. The bottom line is that your game should be OK in Firefox 4. You should see if there is anything you can do to avoid triggering unnecessary GC. E.g. are you re-using variables or creating unnecessary new ones?

However, in Opera 10.53 it was not enjoyable. Not because Opera could not keep up with the speed, but since instead of moving the bottom piece, it was kept stationary and the whole playing field moved instead. (I managed to go to level 17 in my first try in spite of this.) In Opera 10.6 the page fails to load properly.

You probably need to debug your code - or perhaps file a bug with Opera if it's a regression. (I'll tweet this to get their attention.)

I'd blame a large part of it on setTimeout and setInterval having a ~10ms minimum in browsers such as IE and Firefox. This was originally adopted to stop pages from consuming the entire CPU should they naively use 0ms to run as fast as possible. Chrome launched without a limit but is now moving to a 4ms minimum to match the recommendation in HTML5.

John Resig has some awesome posts investigating setTimeout limits and accuracy.

Mozilla browsers can actually tell you how late (or early!) they're running with each setInterval call. Check out the MDC setTimeout article (google "mdc settimeout" and check out the grey note in the syntax section).

Apart from timer problems, Firefox is just generally slower in JS execution (for now at least) and it feels as if Skia (Chrome's graphics lib) is just faster at rasterising too.

Hope this helps :)

(I originally had a bunch of useful links here, but it's my first post and the spam filter slapped me down.)

jQuery animate does something similar to your DOM object movement.

I would look into their code and see how they do the actual movement, it's probably the most efficient way since it's built in jQuery.

Chrome is designed to have a faster Javascript engine.

I don't think it says anything about HTML5 games. You will always find users with faster or slower setups than others, be it hardware, software or a user's personal habit of keeping many applications running at once. If your game were written in Flash or Java, then a user with slower hardware would see a similar slowdown.

You may be able to make changes to your code in order to speed it up. I haven't examined it in great detail, but I see you have constructs like if(dodge.goRight == true .... Although not a source of slowness, this does hint that you may not have used the optimal solution everywhere.

You can test your browser javascript engine with IE site.

http://ie.microsoft.com/testdrive/

They assert to the highest speed javascript engine they have with IE9

Try out this technique: setTimeout with a shorter delay

Let me know if it helps. I'm kinda curious now. :)

Good luck!