4 ms·

Optimizing your JavaScript game for Firefox OS

89 points by rnyman 13y ago

willvarfar 13y 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 13y ago
  Have you tried Firefox's built-in profiler? It really helps a lot – perhaps less so with web workers, though.
  - willvarfar 13y ago
    I have a question open - http://stackoverflow.com/questions/16326495/debugging-and-profiling-web-workers http://stackoverflow.com/questions/16326495/debugging-and-pr... - for anyone who wants to pick up brownie points ;)
- pjmlp 13y ago
  That is what native apps are for.
- PommeDeTerre 13y 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 13y 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...
    - willvarfar 13y ago
      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.
    - 13y ago
- moonboots 13y 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/timeline https://developers.google.com/chrome-developer-tools/docs/ti... [2] https://developers.google.com/events/io/sessions/324908972 https://developers.google.com/events/io/sessions/324908972 [3] http://www.findyourwaytooz.com/ http://www.findyourwaytooz.com/
  - willvarfar 13y 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 13y 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-conquer/ http://www.adityaravishankar.com/projects/games/command-and-...
  - willvarfar 13y 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 13y 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/Profiling_with_the_Built-in_Profiler 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-Performance-For-Madmen https://github.com/kevingadd/JSIL/wiki/JavaScript-Performanc...
  - willvarfar 13y ago
    lovely site! thx for your link
deleted 13y ago
[deleted]
harisaltaf 13y 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.

89 points by rnyman 13y 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 13y ago
Have you tried Firefox's built-in profiler? It really helps a lot – perhaps less so with web workers, though.
- willvarfar 13y ago
  I have a question open - http://stackoverflow.com/questions/16326495/debugging-and-profiling-web-workers http://stackoverflow.com/questions/16326495/debugging-and-pr... - for anyone who wants to pick up brownie points ;)
pjmlp 13y ago
That is what native apps are for.
PommeDeTerre 13y 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 13y 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...
  - willvarfar 13y ago
    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.
  - 13y ago
moonboots 13y 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/timeline https://developers.google.com/chrome-developer-tools/docs/ti... [2] https://developers.google.com/events/io/sessions/324908972 https://developers.google.com/events/io/sessions/324908972 [3] http://www.findyourwaytooz.com/ http://www.findyourwaytooz.com/
- willvarfar 13y 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 13y 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-conquer/ http://www.adityaravishankar.com/projects/games/command-and-...
- willvarfar 13y 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 13y 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/Profiling_with_the_Built-in_Profiler 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-Performance-For-Madmen https://github.com/kevingadd/JSIL/wiki/JavaScript-Performanc...
- willvarfar 13y ago
  lovely site! thx for your link

deleted 13y ago

[deleted]

harisaltaf 13y 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.