Optimizing your JavaScript game for Firefox OS

https://hacks.mozilla.org/2013/05/optimizing-your-javascript-game-for-firefox-os/

by rnyman • 13 years ago

89 17 13 years ago

hacks.mozilla.org

willvarfar6• 13 years ago

I'm working on a webGL game that runs a sim in a web worker.

On Chrome, my sim runs at about 40 ticks/sec on my fancy macbook. Safari and Firefox only get 5-10 ticks/sec.

On an older core2duo HP laptop I see 15 ticks/sec for Chrome and 3-5 ticks/sec for Firefox, on both Linux and Windows.

A new cheap Asus laptop gets numbers very similar to the core2duo, but the rendering works a lot better due to better graphics card.

I want to move some priority queue code I have to handwritten asm.js when I get time, but don't expect it to make a big impact.

Its just so hard to actually profile your code and understand your bottlenecks. What happens in web workers is basically invisible.

Before I had web workers my putting sim ticks into the render callback was making the game very unresponsive, particularly in Firefox.

I dream of the game working on tablets etc, but that seems a long way off.

Games like the original simcity and tycoon series and a-train all worked well on really really low-end machines, at performance that seems out of reach for javascript games that basically work the same :(

Yoric• 13 years ago

Have you tried Firefox's built-in profiler? It really helps a lot – perhaps less so with web workers, though.

willvarfar6• 13 years ago

I have a question open - http://stackoverflow.com/questions/16326495/debugging-and-pr... - for anyone who wants to pick up brownie points ;)

pjmlp• 13 years ago

That is what native apps are for.

PommeDeTerre2• 13 years ago

What you describe is a reoccurring theme when it comes to JavaScript applications in general, but it's much more visible when games are involved.

The unfortunate reality is that JavaScript, WebGL, and these other technologies running on extremely powerful computers (even if we're talking modern mobile devices) still can't compete with games written back in the 1980s, in C and assembly, which ran perfectly fine on what are now 25-year-old 386 PCs with a mere fraction of the processing capabilities of a modern system.

As an industry, or even as hobbyists, we should not be in this position. At best, we can call the current situation a complete stall in advancement. At worst, but more realistically, it's been a significant step backward.

antimagic• 13 years ago

It's not really a fair comparison - much of a game's work is pushing pixels, and today's systems have an order of magnitude more pixels to push (1080p = 2MegaPixels, 640 x 480 = 300 000 pixels).

Today's game written in Javascript will also run on numerous different CPU architectures, on different OSes. This generality means that you can't take advantage of platform specific hacks that allow the eking out of every last scrap of performance from the silicon.

So yes, when you make a game do a lot more work, and you want it to run on multiple platforms, forcing optimisations to be platform-agnostic, you shouldn't be surprised that it's hard to match the performance of 25 years ago. On the other hand, if you use the same technologies as 25 years ago, you'll smash the performance from back then. Likewise, if you try to run SimCity in a browser ported onto a 386 PC, it would be an insult to dogs to say that it runs like a dog...

daredevildave• 13 years ago

What? Sorry, that's just not true.

MS-DOS games in 1992: http://www.youtube.com/watch?v=D6E4FZdY-pM

JavaScript games/tech in 2013: http://playcanvas.com/demos/ http://services.runescape.com/m=itemdb_rs/bestiary/?show=50

moonboots• 13 years ago

I recommend temporarily disabling web workers, which should provide better visibility into js bottlenecks in tools such as Chrome's timeline panel [1]. Also check out this google IO talk [2] on performance debugging the WebGL/HTML5 demo "Find Your Way to Oz" [3].

[1] https://developers.google.com/chrome-developer-tools/docs/ti...

[2] https://developers.google.com/events/io/sessions/324908972

[3] http://www.findyourwaytooz.com/

willvarfar6• 13 years ago

Yeah I've been playing around with those tools, but they give little insight into how to improve performance on browsers other than chrome.

teamonkey• 13 years ago

Yes, there is definitely a disparity between native code and Javascript running in the browser. Yes, different browsers have different performace bottlenecks, and yes, different hardware configurations and GPU also have a huge impact.

On the other hand, you're talking about having problems recreating games that ran on 16Mhz CPUs with 1MB of RAM, which makes me somewhat sceptical.

I don't mean to be disparaging, but I expect that there's something in your main game loop that is killing your performance, and that even if you ported it to asm.js or C++ you would still have the same bottlenecks (perhaps masked better on modern hardware by the better native performance).

As a counter-example, a reasonably complete and functional HTML5 port of a game from the 90s: http://www.adityaravishankar.com/projects/games/command-and-...

willvarfar6• 13 years ago

Doubtless it'll come down to some silly mistakes, like having a `for(var attrname in obj)` (as was the construct that caused V8 to unoptimise their Oz game, link above). I've been coding for long enough - started with the ZX81 and 286 - to know we're all mortal.

The tools for finding this stuff suck. The tools for finding and fixing this stuff for just a handful of mainstream browsers - Firefox, Chrome and Safari - suck.

I want Chrome and Firefox to show code hotness inline in their script browser panes of their developer tools. I want profiling to work for web workers. I want all this without needing to compile my own copy of V8 (as Google advocate in the video above).

Just when profiling, electric-fencing and static analysis begin to become mainstream for C++ developers, we're thrown back to basics in browsers.

Just because wanting to see asset load and understand the fold are mainstream profiling problems for people making shopping websites, doesn't mean browsers aren't going to get used more and more for gaming-style workloads and will need the profiling and debugging tools that problem demands.

kevingadd• 13 years ago

If you're seeing miserable performance in everything other than Chrome, something is probably wrong with your Javascript, or you're doing something that is only optimized in Chrome.

Given that you said web workers, are you transferring a lot of data between the worker and the document? Web worker transfers are pretty expensive, so it's possible you're seeing the effect of Chrome having a faster implementation.

Does your JS generate a lot of garbage, and cause GC pressure? Chrome's collector handles garbage better than Firefox because it's generational, but getting rid of GC pressure can improve performance everywhere.

I feel your pain about the difficulty of profiling web workers, though. Profiling browsers in general is a pain but it seems like none of the dev tools people on any browser actually bother to make tools work with web workers.

In FF I strongly recommend using the SPS Profiler because it will give you incredibly detailed performance data; however I don't know if it works with web workers either: https://developer.mozilla.org/en-US/docs/Performance/Profili...

My list of JS perf gotchas might contain one or two helpful details for you as well: https://github.com/kevingadd/JSIL/wiki/JavaScript-Performanc...

willvarfar6• 13 years ago

lovely site! thx for your link

harisaltaf• 13 years ago

For canvas games I recommend locking viewport to device-width and disable scaling. The scaling mechanism mentioned before is mostly for letting the game canvas adapt to multiple screen sizes and works also good on desktop.

Optimizing your JavaScript game for Firefox OS

Related Stories