Optimizing your JavaScript game for Firefox OS | Hacker News Reader

Optimizing your JavaScript game for Firefox OS

hacks.mozilla.org

89 pointsrnyman17 comments

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 :(

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

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

That is what native apps are for.

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.

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...

I think its an entirely legitimate observation.

The screens are bigger, but the CPUs are several orders of magnitude faster ... on paper.

As I specified that it was a webGL game, we understand that actually there's more CPU than ever to focus on the actual sim crunching.

Its a sad observation that there is approaching an order of magnitude performance gap between chrome and FF on this type of Javascript performance, and many orders of magnitude between JS and bare metal.

But the difference between NaCl and native is almost nothing, and that's almost as portable. Even PNaCl has almost native performance, and that's precisely as portable as JavaScript.

The web as a platform is terrible, despite the amazing work of browser vendors.

There are only about 7 times more pixels in the modern system in your example.

Yet in the same time, x86 processors have gone from 25 MHz to 3,000 MHz, if not higher. That's a difference of 120+ times.

That's not even considering that basically all PCs (including laptops) and many mobile devices, now have CPUs with at least 2 cores, although 4 or 8 cores is pretty typical, too. Back then, uniprocessor PCs were really the only practical option.

The amount of memory available today is significantly larger, too. At the end of the 1980s, it was impressive to have 2 MB of RAM in a desktop PC. These days, we're generally looking at 4,000 MB of RAM, if not more. That's 2,000+ times more RAM today! When it comes to mobile devices, we're still looking at hundreds of times more RAM. The speed of memory today is also much faster than it was back in the 1980s.

And, of course, we've seen absolutely massive strides in video card technology in that same period of time.

Given those kinds of increases in the power and amount of resources that are available now, JavaScript and the other web technologies have absolutely no excuse for performing as poorly as they do.

I don't even buy the argument that JavaScript is much more portable than C was back then. SimCity was ported to many, many platforms. I remember playing it on PCs running DOS, on an Amiga, and even on an SNES at one point.

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

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/

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

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-...

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.

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...

lovely site! thx for your link

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.

Reply on news.ycombinator.com