4

I have ported a game engine project for my university course from C/C++ to JavaScript using emscripten. The asm.js optimization flag is set and I have been measuring the performance. But what is puzzling is that the performance in Firefox is bad. While the project runs very well in Chrome and Opera. This doesn't make sense to me given that FireFox is the browser utilizing asm.js optimization.

This project is a downhill slalom racing game using SDL and WebGL. Running in Firefox on my laptop the profiler shows that the demo is completely bound by the CPU, the bottleneck appearing around _SDL_LockSurface() and _TTF_RenderText_Solid(). These are used to render the dynamic text among other things.

And yet in Chrome the CPU is idle most of the time on the same system. And performance is similar in Opera. Does this mean the asm.js optimization is not working? Firefox reports the asm.js code has compiled successfully. So why is this optimization backfiring and resulting in execution that is at best half the frame rate? I've tested with FF version 28, also the current nightly build. The demo can be found here, http://www.susurrus.mars-station.com/page7.php?lang=en

Culzean
  • 349
  • 3
  • 13
  • Possibly related. Not sure. http://stackoverflow.com/questions/17951449/firefox-does-not-seem-to-be-faster-using-the-asm-js-profile-yet-chrome-is – cookie monster Apr 25 '14 at 01:54
  • It is along the same lines. The best answer to that question is that there is a cost to call js functions from ams.js and vice versa. I don't see any sign of this in my case.. though either way I would like a more definitive answer. – Culzean Apr 25 '14 at 02:06
  • 1
    Yeah, I didn't really think that was a duplicate. Just a little extra info. I get over triple the frame rate in Chrome. I think I remember hearing that they basically have tried to optimize for ASM, but without requiring the declarative, so it could be simply that it's better optimized. Not sure though. – cookie monster Apr 25 '14 at 03:06
  • 2
    SDL_LockSurface() and TTF_RenderText_Solid are both graphics calls, no? So chances are it's the graphics bits of this that are slow, not the asm.js bits.... – Boris Zbarsky Apr 28 '14 at 19:04
  • Yup, they graphics calls. But these run without difficulty on the same system but under Chrome. – Culzean Apr 28 '14 at 19:12

1 Answers1

0

I was thinking about this question for a long time and I might have an answer for you. Simply, get rid of canvas.getContext('2d'). I guess asm.js is not your problem at all.

As @BorisZbarsky said, these are graphic calls that has nothing to do with asm.js. You answered that these run without difficulty. I tested it on my own and a lot of things that can follow after getContext as 2D is heavy graphic operation, that you really can't do at realtime fps.

Simple example there: http://jsfiddle.net/windkiller/8r3gP/ It is very simple animation, but it eats 60% of my cpu.

Entity Black
  • 3,401
  • 2
  • 23
  • 38
  • It's a webgl application, so both the GPU and CPU are being utilized in this case. Perhaps I didn't make that clear. The asm.js function is using ~80% of the CPU which is maxed out in Firefox. So a full 23% of CPU time is spent in SDL_Locksurface. These functions do not appear in the CPU trace for the exact same program running in Chrome. I don't understand what you mean get rid of getContext. – Culzean May 04 '14 at 00:42