Javascript Speed ​​- Chrome v Firefox

Question

I wrote this little game at http://amarnus.me/games/dodge . Now, if you try to play the game in both Firefox and Chrome, you will obviously notice that Firefox is much slower. Yes, it can be called an unintended cheat code .; -)

So my question is: is this because of the slower Javascript mechanism in Firefox compared to Chrome? Or does this have anything to do with bad coding ? (In my defense, I am javascript newb)

Assuming this is the first, then is this not a problem against the (lack) of HTML5 games? (Those using the <canvas> as mine)

Answer 1

Firefox is slower than chrome in javascript. However, I find that it also uses the canvas tag more slowly. This will probably improve with ff4 (have you tried beta?).

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

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

I believe that browser games will come on time, but they are not yet ready for something too advanced. Maybe around the time that ie12: -P appears.

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

Answer 2

To get help, you might consider providing an un-shortened version of your script.

I see that your code has 8ms setIntervals. As mentioned above, Firefox never drops below 10 ms (yet). However, playing FFox 4 is very nice. I saw two very small hicks that were clearly caused by garbage collection. Chrome has an edge over Fox in this regard. Although SpiderMonkey (which handles the GC in Firefox) has improved significantly from 3.5 to 3.6, it is still not good enough for many games. In 4.0, this is much better, but still not as good as in Chrome or Opera. (He works.)

While playing the game and looking at your code for a short time, I don’t see any difficulties that could cause Firefox to be unable to cope with what is happening. In addition, Firefox 4 has Canvas hardware acceleration, which is slightly faster than IE9 and much faster than Chrome.

There is a concept on the Internet that Chrome is faster than Gecko when it comes to canvas, but this is because people rarely profile their pages. In fact, the canvas in Firefox 3.6 is already at least as fast as in Chrome, but many tests do not show it, because JavaScript is slower. (And some JavaScript tests are slower because Firefox cannot handle the test harness.)

All this leads to a lot of confusion and misinformation. The bottom line is that your game should be fine in Firefox 4. You should see if there is anything you can do to avoid running an unnecessary GC. For example. Are you reusing variables or creating unnecessary new ones?

However, in Opera 10.53 it was not very nice. Not because Opera could not keep up with the speed, but because instead of moving the lower part, it remained stationary, and instead the entire playing field moved. (Despite this, I managed to rise to level 17 in my first attempt.) In Opera 10.6, the page does not load properly.

You will probably have to debug your code - or perhaps a file from Opera, if it's a regression. (I will be tweeting to get their attention.)

Answer 3

I would blame most of this for setTimeout and setInterval, having at least 10 ms in browsers like IE and Firefox. This was originally taken to stop the use of the entire processor pages if they naively use 0ms to work as quickly as possible. Chrome is launched without restriction, but now it will move for at least 4 ms to comply with the recommendation in HTML5.

John Resig has several awesome posts exploring the limitations and precision of setTimeout.

Mozilla browsers can actually tell you how late (or earlier!) They work with every setInterval call. Check out the MDT setTimeout article (google "mdc settimeout" and check the gray note in the syntax section).

Besides the problems with the timer, Firefox tends to work slower when running JS (at the moment, at least), and it seems that Skia (Chrome graphics lib) is faster at rasterization.

Hope this helps :)

(I initially had a bunch of useful links here, but this is my first post and the spam filter hit me.)

Answer 4

jQuery animate does something like your moving a DOM object.

I would look into their code and see how they make the actual movement, this is probably the most efficient way since it was created in jQuery.

Answer 5

Chrome is designed to have a faster Javascript engine.

I don’t think he says anything about HTML5 games. You will always find users with faster or slower settings than others, whether it is hardware, software or a personal habit of the user, allowing you to simultaneously run multiple applications at once. If your game was written in Flash or Java, then a user with slower hardware will see a similar slowdown.

You can make changes to your code to speed it up. I have not studied it in great detail, but I see that you have constructions such as if(dodge.goRight == true ... Although this is not a source of slowness, this suggests that you may not have used the optimal the solution is everywhere.

Answer 6

You can test the JavaScript engine of your browser using the IE site.

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

They claim they have the fastest JavaScript engine with IE9

Answer 7

Try this technique: setTimeout with less delay

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

Good luck