Box2D, Update Rate, and Paint Rate for JavaScript

Sponsor: Register today for New Game, the conference for HTML5 game developers. Learn from Mozilla, Opera, Google, Spil, Bocoup, Mandreel, Subsonic, Gamesalad, EA, Zynga, and others at this intimate and technically rich conference. Join us for two days of content from developers building HTML5 games today. Nov 1-2, 2011 in San Francisco. Register now!




Last article we looked at running Box2D inside of a Web worker, with promising results. We will revisit Web workers in a future article. For now, let us return to a single thread.

Intro

After reviewing some of these recent Box2D posts, my colleague Boris Smus pointed out that I've missed an obvious example test. It would be interesting to see what happens if we twiddle two knobs: the update frequency and the draw frequency. I realized my previous articles don't address this experiment, so I present to you:

Moar Knobs

The example below now allows you to configure the number of bodies to simulate and render. I've bumped up the default to 100 for a more strenuous test.

You can now enable or disable individual simulations. Don't want to run side by side? No problem, turn one off to check performance.  (Note: we'll introduce Web workers with another article for a better side by side comparison)

I've modified a previous experiment to include a new knob: "How often we call world.step()" which is a long winded way to say "Update frequency".  This knob controls how often update() is called, which in our experiment, calls world.step().

The experiment still contains the previous knob for FPS which is draw() aka paint() frequency. This means we can draw more, or less, than we update, to see what effect it has on performance, both real and perceived.

Example


(The example below is available as a stand alone full side by side version.)



Try changing FPS to 30Hz and Time Step and world.step() freq to 60Hz. Or turn FPS up to 60 and turn Box2D down to 30. What do you see? How does it compare?

Results

Right (top) side:

  • FPS: 60
  • Box2D Time Step: 60
  • Adaptive: Off
  • Update: 60
  • Num Bodies: 100
  • Run Sim: On
Left (bottom) side:
  • FPS: 60
  • Box2D Time Step: 30
  • Adaptive: Off
  • Update: 30
  • Num Bodies: 100
  • Run Sim: On
For this simple 100 bodies simulation with the above configuration, the left (bottom) side seems to display a less smooth experience. Bodies however do end up approximately in the right place and approximately the right time.

I do see some Box2D correction as bodies seem to overlap sometimes in the Left/Bottom test.

What was surprising for me, though, was that the Left/Bottom side seemed to run faster. On my machine, the bodies on the Left didn't seem bogged down like the bodies on the Right. Bumping the number of bodies back down to 10 for both sides shows a matching speed, so it appears that running the physics simulation only half as much as your render loop helps the world performance maintain a constant speed.

Of course, we're running two simulations on the same thread in the browser, so we're affecting the performance of both simulations.

Open Source

Check out the source code and run the stand alone example.

Next Steps

Now that we have Moar Knobs and a more complex simulation, we will merge the Web worker example with this example for a better side by side test. By moving all Box2D simulations to separate processes, we will hopefully get a better sense of performance characteristics after we twiddle the knobs.

In the meantime, check out the next article on incorporating the Page Visibility API with Web workers and Box2D.

Popular posts from this blog

The 29 Healthiest Foods on the Planet

Lists and arrays in Dart

Converting Array to List in Scala