Engine Configurations lead to Optimizations

Yesterday I revisited the new configuration module in The Render Engine.  What I probably forgot to blog about was that I've been working on a way to load browser-specific configurations to help tune and optimize the engine.  The first iteration was simple and only loaded a simple object with configurations for the type of browser being used.  Turns out, that was too generic to handle some of the things I want to support.

Being ambitious, I've updated the config module to load a configuration which should be more flexible.  For example the Firefox config looks something like this:

{
   "versions": {
      "4.": {
         "transientMathObject": true
      }
   },

   "platforms": {
      "Windows 7": {
         "4.": {
            "hardwareAccel": true

         }
      }
   }
}

What this configuration does is allow us to set up some options which differ from the defaults.  For example, transient math objects and hardware acceleration are disabled by default.  With Firefox v4.0b6, hardware acceleration on Windows 7 has been enabled by default so this config sets a flag which the engine (or a game) could use to take advantage of that.  Also, in Firefox v4.x, using transient math objects tests faster than pooling them.

So, they're just flags but they do help in making determinations while the engine, or a game, is running.  For example, knowing that hardware acceleration is available, the drawImage() call of the CanvasContext is much faster.  So, it makes sense to use the Billboard2DComponent in the vector demo instead of always drawing the vector object's polys.  When I profile in Firebug, the calls to drawImage() in Firefox 3.6.9 take up > 5% of the overall time (right at the top) with only 3000 calls, compared to just drawing the polys which takes ~ 1% of the overall time with over 120,000 calls.  However, using the billboards in Firefox 4.0b6 those 3000 calls take up < 0.01% of the overall time.

You should know that these are just guesses based on the defaults that the different browsers use.  As such, if someone disabled the Direct2D acceleration in Firefox 4.x, the engine can't determine that purely in JavaScript.  So, while these aren't foolproof, they will help the majority of people who don't mess with their configurations.