Game Development Stack Exchange is a question and answer site for professional and independent game developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

In my experience, even till this day, I still see more of a visual lag in entity movement / animation in JavaScript (Canvas) based games than I do in Flash based games.

Why is this - what exactly is the descrepancy at the most basic level between an JIT vs AOT compiler in the specific scenario of JavaScript vs. Flash.

share|improve this question
Flash code in the browser is not compiled ahead of time; the Flash Player includes a virtual machine for interpreting the code. The only platform Flash supports through AOT compiling is iOS. – jhocking Jun 5 '12 at 11:58
up vote 4 down vote accepted

It's not the compilation method that makes the games lag, it's the garbage collector, and the Flash garbage collector is separate from the browsers.

I think I can pretty confidently reason that you run Firefox, because the Firefox garbage collector is the worst piece of crap you can get, from a gaming point of view. If you open just one tab and run a light JavaScript game in it, it is usually tolerable, maybe even unnoticeable. But if you open a bunch of tabs, run something a bit more demanding or use Firebug you'll easily get regular lag spikes beyond 100 ms.

I haven't done any extensive testing for a while, but Chrome has always done really well in this regard, and both IE9 and Safari seemingly do an acceptable job as well.

I made a tool for testing JavaScript lag, you can play with it if you like:

share|improve this answer
I actually use chrome because of the exact reason you states above, I almost threw garbage collection into the mix above but wanted to keep the question focused. Even in chrome, the garbage collection still causes this visual lag comparative to flash. So from a naive perspective - what is the solution to this problem (besides just "better garbage collection")? – Anthony May 30 '12 at 19:36
@Anthony Funny, I don't see this problem in Chrome at all, do you get anything but green bars if you run my lagtest? Of course you can always write a program that simply take too long to execute at some point, you are sure that is not the issue? – aaaaaaaaaaaa May 30 '12 at 20:23
FF's been disturbingly fragile for the last couple years. Not sure what that's about but the constant releases that do nothing but force plug-in authors to adapt/upgrade while serious bugs get ignored smells like misapplied agile or scrum to me. It's a damn shame. – Erik Reppen Jun 6 '12 at 2:39

It's hard to say without looking at actual code but a few points:

  • Flash has been around longer. People who author tools and libraries for it have more experience handling animation. I'm not a big fan of the tools and the proprietary technology but I'll never knock an ActionScript dev who knows what s/he's doing.

  • JIT browsers are also relatively new to JS developers. The best choices for really fine-honed perf-intitiatives are still something we're sorting out as a community. Inline function defs used to be a borderline dumb thing to do in a lot of cases. Now it's a great way to boost perf in a lot of JIT scenarios.

  • Normalizing for umpteen browsers doesn't have to but often does result in failing to take full advantage of a given browser's full capabilities.

  • (edit: not quite right on this one but there might still be a point here - Erik) The Flash plug-in is vector friendly and it is widely understood how to take maximum advantage of that. Whether inheritance schemes will do us a ton of good with canvas context objects remains to be seen but I doubt it will be to the same degree of win you get out of vector.

share|improve this answer
I need to personally read up on some of the terminology but this is a great answer as well. – Anthony Jun 5 '12 at 15:42
I think I was wrong about the vector side of it. Canvas does have vector-based API methods baked into it. I think I was mal-corrected on that recently by somebody who just made faulty assumptions about the fact that you're always outputting bitmaps. Been reading O'Reilly's Supercharged JavaScript Graphics on the train and I highly recommend. – Erik Reppen Jun 6 '12 at 2:29

One interesting thing that I'm surprised nobody has mentioned yet is the difference in the types of JIT compilation, because Flash is still JIT compiled, and, in most modern browsers, so is JavaScript, however Flash is a strongly typed language, which means there are a whole realm of optimizations that it can do (such as emitting a call to a method directly (something JavaScript cannot do)), that JavaScript cannot do because it is dynamically typed. You can replace the entire definition of a function in JavaScript at any point you want, and that new definition is what must be called. (it is still possible for JavaScript to do an indirect call that wouldn't be that much more expensive though) Field access on a field is actually a better example than method calling, because JavaScript cannot even do this indirectly, it has to first look the field up by name (hashed) on the current type of the object.

Another difference in performance is, as is already mentioned, the GC. I suspect (I've not checked) that most browsers use either a reference counting GC (because all memory the GC allocated for a page can be freed when the page is left, it's actually one of the best places to use a reference counting GC), or a conservative scanning GC (such as Boehm). The latter can be considerably slower than the former if it's not implemented right. (Boehm is an example of a right implementation) Flash on the other hand uses a precise GC (much easier to do in a strongly typed system). Because Flash uses a precise GC, it doesn't have the runtime overhead of reference counting. (which isn't huge, but is still there) A good example of a precise GC is Mono's SGen, which also compacts the heaps.

Then there comes the fact that JavaScript wasn't designed with animation in mind. (as was also mentioned) As far as I know, no browser will emit SSE-style instructions for the animating loops, where-as the core rendering functions in Flash have probably been hand optimized for peak performance. (in some places being written in raw assembly)

All-in all, it comes down to the fact that a dynamic language will always be slower than a statically typed one if it has to be compiled in a timely manner so as to not make the user complain about it's slowness.

share|improve this answer
Java is also strongly typed and highly performant when you do the benchmarks. I'd still bet on Node.js devs vs. the Java devs in a performance contest for a basic server-side web app assuming just above mediocre talent-levels. Strong vs weak types is a design tradeoff, not a guarantee your app will run faster when left to human hands that do stupid things when there's a lot more code to juggle. Not that I'd recommend writing a 3D engine in JS, Flash, or Java. – Erik Reppen Jul 18 '13 at 1:26

IMHO that differnece comes from the fact that Flash was build from the ground to do exactly that, animations. Flash implements (even though poorly by major judgement) techniques for smoother visualization running by default, when in JS you would need to make those implementations manually.

There are examples of great implementations of JS/Canvas running even better then most Flash games I see around. It all comes to the developer making them.

share|improve this answer

aside from the GC, JIT aspect of these technologies, there is gap between the usage of hardware.

in the latest version of flash player, flash has began resort to hardware acceleration for rendering those images, which makes the rendering process faster and quality better. while on the other hand, JS driven games on some browsers( FF, CHROME ) haven's started this yet. There was one exception though, the IE9 browser has began to re-architect from the hardware abstraction layer, browsers from IE9 had made tremendous progress on making use of hardware acceleration, thus graphics rendering on these browsers is definitely better and faster than other browsers.

share|improve this answer
Just as a side note, in chrome/ff you can force hardware acceleration (webgl), whether it is done via code and/or browser config settings, the slight advantage is available. In any case my assumption is the implentation in chrome/ff is still more immature than in IE 9+ – Anthony Jun 6 '12 at 14:17
@Anthony yep, definitely agree. now days in the graphics API realm, DX is exceeding OPENGL quite a bit, and no way that chrome or other browsers can do better than IE9, at least for a short period. – zinking Jun 7 '12 at 1:51

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.