
As we close in on our year-long goal of bringing [BattleTabs](https://mikecann.blog/posts/battletabs-in-7-minutes) to mobile the time has come for some long-overdue performance improvements.

I have been putting it off as performance improvements are always a bit of a project-black-hole sucking all time, space and energy. Fortunately I was able to escape this relativistic singularly and come out of the other side with some sizeable performance gains and interesting insights in tuning a BabylonJS game that I thought I would share here.

# Before Getting Started

First thing's first. When attempting any sort of performance optimization pass its critical to lay a good foundation down first. We need to first get some good diagnostics info from the game. This allows us to see which parts of our game are causing the performance drops.

Fortunately BabylonJS has some pretty good metrics built into the engine that you can checkout in the inspector:

[![](./babylon-inspector-stats.png)](./babylon-inspector-stats.png)

It unfortunately doesnt show me those numbers as a percentage of frametime and it also takes up quite a bit of the screen. So I decided to make a little stats counter in the top left that shows me the critical numbers and their percentage of the total frame.

[![](./my-stats-counter.png)](./my-stats-counter.png)

With this in place I was able to start to narrow down what I think I can spend some time looking to a little more deeply.

One other quick tool I like to use is Chrome's CPU throttling feature:

[![](./chrome-cpu-throttle.png)](./chrome-cpu-throttle.png)

I develop the game on a powerful desktop PC which is likely more powerful than many of our users' devices. So using the CPU throttle it lets me simulate what its like for them a little more closely.

Arguably this slants things more towards a CPU bottleneck rather than a GPU bottleneck but lets just ignore that for now, ill discuss it more a bit later.

# Problem Areas Identified

I quickly noticed that there were three large contributors towards the total frame time: "Mesh Selection", "Animations" and "Render".

## Render

Render is a pretty obvious one, it's the time for the GPU to get the pixels on the screen. There was likely some stuff I could do here to speed things up but I decided not to tackle this one for now as it was likely going to involve some quality tradeoffs or digging through shader code which I would rather not do just yet.

## Mesh Selection

I wasn't too sure what this meant but after reading [Babylon's performance documentation](https://doc.babylonjs.com/features/featuresDeepDive/scene/optimize_your_scene#freezing-the-active-meshes) I had a better idea. As far as I understood it, it is the time taken for Babylon to choose which meshes it should send to the GPU for rendering. This is dependant mainly whether the mesh is within the camera view area (Frustrum).

BattleTabs doesn't really have many meshes and most of them are on screen most of the time so I wasnt really sure why exactly this number was so high.

I decided to [raise this issue on the BabylonJS forums](https://forum.babylonjs.com/t/why-is-mesh-selection-time-so-high-and-how-to-reduce-it/47069).

[![](./forum-post.png)](./forum-post.png)

After a bit more experimentation I added a "FREEZE" button to my stats which called the `scene.freezeActiveMeshes` which was also mentioned in the Babylon performance docs. This had a dramatic effect on the Mesh Selection time, effectively removing it.

<iframe width="100%" height="480" src="https://www.youtube.com/embed/HtVbtbm8I5w" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>

As far as I understand it, freezing active meshes means that whatever is currently "active" (viewable within the Camera Frustrum) will ALWAYS be incuded in the list of meshes to be rendered.

This is great as it removes all that frustum culling time but it has a nasty side effect. If anything is added or removed from the scene, or its visibility changes, then it wont be reflected on the screen. This is because the mesh selection is "frozen". Animations also froze (im not exactly sure why this is).

All of these issues were possible to work around but it was going to be a bit of a pain going through the code with a fine-toothed-comb looking for places that might cause problems. Not only that it was likely to cause future bugs as its a nasty cross-cutting concern you can often forget.

I decided to sit on this one for now and look into the final large chunk of frame time I had yet to explore.

## Animations

Animations were taking over a third of frame time, this was a surprise to me. We only have 4-8 ships animating at any one time and [I was under the impression that babylon's skeleton animations were computed on the GPU](https://doc.babylonjs.com/features/featuresDeepDive/mesh/bonesSkeletons#picking-a-mesh-attached-to-a-skeleton) so there was no reason why they should be so slow.

I had read others having issues with this in Babylon and they suggested [that one could bake their animations](https://doc.babylonjs.com/features/featuresDeepDive/animation/baked_texture_animations) into whats know as "Vertex Animation Textures (VAT)".

These are basically pre-computed positions for each (bone? vertex?) each frame. These positions are stored in a giant array then loaded a runtime, passed to the GPU then used in a shader to update the positions of each bone / vertex each frame.

Doing this was going to be a bit of a pain as it meant we would have to add an additional design-time step of producing these VATs for each ship (and skin) and keeping them updated any time a change is made. It also precluded us from using blended animations, but we werent using those so I wasnt too bothered about that.

As with all performance work I did the bare minium of absolutely the nastiest-hackyiest code I could to test the theory and was surprised that VATs actually worked:

<iframe width="100%" height="480" src="https://www.youtube.com/embed/gIfKTqxTS4o" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>

VATs meant slower game loads as each animation for each ship now had to load in another texture. It likely also meant more VRAM usage as these new textures had to be sent to the GPU but I suspected this tradeoff was going to be an acceptable one for BattleTabs so I ploughed ahead.

# Putting it all together

With the theories in place and experiments conducted I reset my git branch and started again, this time properly coding it up. This was an arduous process as it meant handling lots of edge-cases that the experiments didn't cater.

Eventually I thought I had it all looking pretty good. To make sure I had the problem solved I put together a torture test scene:

<iframe width="100%" height="480" src="https://www.youtube.com/embed/xJ8DGv_NzAE" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>

The above shows that even with 100 ships animating I wasnt spending any time in Mesh Selection or Animations, huzzah!

# Conclusion

So in total I saw about a 70-100% performance improvement once I set my CPU throttle to 6x slowdown. This is quite a nice gain and makes me question why BabylonJS as an engine doesnt put more effort into reducing CPU load as JS is inherantly single-threaded and GPUs are so powerful these days it seems to me that the CPU is almost always going to be the bottleneck.

When I quizzed Evengi_Popov one of Babylons core-contributors he agreed:

[![](./jedi.png)](./jedi.png)

So who knows, perhaps we will see some of this stuff built into the engine in the future.

For now im happy with the results, theres always more that could be done but I think its taken a little bit of pressure off of many of our users' poor devices and given them a better gaming experience.

Now onto the last few things before the mobile release!


Its no secret that im a bit of a tinker'er and this blog seems to bear the brunt of my experiments.



# TLDR;

This site now uses [NextJS](https://nextjs.org/) hosted on [Vercel](https://vercel.com/).

# History

This blog started [way back in feb 2003](https://mikecann.blog/posts/snakez-2003) with some simple flash experiments. Back then it was itself a flash site (they all were at the time!). Over the years however it went through many iterations. 

Some time in 2006 it became a Wordpress site, which it stayed for quite some time. I never was happy with the performance on Wordpress however so [in 2017](https://mikecann.blog/posts/the-static-blog) I decided to move the blog to Hexo a static site generator. This allowed the site to be super fast because all the posts and pages were pre-rendered as simple HTML pages during build time then served from the AWS CDN close to the user.

Although I was happy with the performance I wasn't happy with the development process with Hexo, it felt very messy and archaic using bower for dependency management. It also took ages to build the blog which by that point has amassed 14 years of posts.

So [in 2019](https://mikecann.blog/posts/migrating-from-hexo-to-gatsby) I moved from Hexo to the popular Gatsby static site generator. This was definitely more modern and was highly configurable however I personally am not a fan of using GraphQL for accessing assets locally, it all just felt very complicated. It also took a long time to build everything.

# Now

So now enter NextJS. This is a very "in" framework at the moment that allows you to write your "app" in React but have parts of it rendered server-side and parts of it run locally in the browser. 

"But, but, Mike!" I hear you cry "server side rendering, wont that be like going back to the slow-old-days of wordpress where everything has to go to a central server before being rendered and delivered to the client?". Ah you see I thought that too that I discovered that the creators of NextJS, Vercel, have a cloud offering that solves that.

Vercel cloud uses "edge" servers to render the page then deliver it to the client. These "edge" server run very close to the client requesting the page and thus like a CDN they are able to load, render and deliver very quickly to the client. I dont think it can ever be quite as fast as a CDN but its pretty indistinguishable from what I can tell.

# Result

So the result is I now have a blisteringly fast blog that is a joy to develop in and builds quickly!

Hopefully I dont need to move again for a long time, but then again I think I said that last time :P

[![](/wp-content/uploads/2011/07/header.png "header")](/wp-content/uploads/2011/07/header.png)

Ive spent a little more time this weekend looking at some more  HTML5 with HaXe. Following on from [my previous experiments with WebGL](/posts/chrome-crawler-haxe-three-js-webgl-and-2d-sprites/) I decided to give HTML5's Canvas a a look as it was supposed to be designed specifically for the purpose of doing 2D.



I had heard from the HaXe mailing list that the [Jeash project](https://haxe.org/com/libs/jeash) was a common way of interacting with the canvas in HaXe. Jeash is a remapping of the Flash API into JS so in effect I should beable to take any of my usual flash code, Sprite's,  BitmapData's, etc and it should run on the canvas no problems. Nice!

So I coded up a quick blitting example to see what sort of performance I would get:

[/projects/HTML5SpeedTests/HaXeJeash/bin/](/projects/HTML5SpeedTests/HaXeJeash/bin/)

The results were okay (I get about 11FPS with 5,000 crawlers) however I was interested to know what sort of cost HaXe adds. So I decided to code up a second example, this time using pure JS:

[/projects/HTML5SpeedTests/JSCanvas/](/projects/HTML5SpeedTests/JSCanvas/)

The results this time were better (14FPS with 5,000 crawlers) so I now wondered what happens if I do without Jeash and just code up the example using pure HaXe. I was expecting to see the same sort of performance hit as Jeash:

[/projects/HTML5SpeedTests/HaXeCanvas/bin/](/projects/HTML5SpeedTests/HaXeCanvas/bin/)

Surprisingly it actually runs faster (17FPS with 5,000 crawlers) ! This is quite a surprise and totally contradicts my notion that going from HaXe -> JS would incur a cost. I was expecting some cost, but a performance increase?! I can only speculate that behind the scenes the JS engine in the browser is able to JIT compile the HaXe JS much better than the hand-crafted JS and hence more speed.

If you are interested in the source then I have uploaded it here: [/projects/HTML5SpeedTests/HTML5SpeedTests_1.zip](/projects/HTML5SpeedTests/HTML5SpeedTests_1.zip)

P.S. All the test were run on Windows 7 x64 in Chrome 14 (dev)

[![](/wp-content/uploads/2011/02/Shot_01.png "Shot_01")](/wp-content/uploads/2011/02/Shot_01.png)

Been a long time since I have updated this little project of mine. Yep, just checked, its [been almost a year ](/posts/windows-7-taskbar-monitor/)since.



Oddly enough this is one of my projects I actually use on a daily basis at home and work. Im not sure why I haven't updated it since as there have been some rather gaping bugs in it which have been very annoying but apparently not annoying enough to encourage myself to fix them or to stop using it.

Anyways, I have finally decided to fix some of the most anoying issues namely:

- It no longer crashes when the network is lost
- It now correctly reports the amount of physical memory used
  Theres no auto-updating feature built into the tool so if you are looking for the upgrade head over to the google code page to grab it: [https://code.google.com/p/win7-taskbar-mon/downloads/list](https://code.google.com/p/win7-taskbar-mon/downloads/list)

Wow! Just noticed that over 2000 people have downloaded the first version, didn't think it was that popular!

Oh yes, I have also uploaded the latest source for this version: [https://code.google.com/p/win7-taskbar-mon/source/checkout](https://code.google.com/p/win7-taskbar-mon/source/checkout)

Enjoy!

Well this will learn me!

A while back, I had an idea for a very simple application that would sit in your taskbar and give you at-a-glance performance info about your system, similar to[ iStat Pro for OSX](https://www.islayer.com/apps/istatpro/). This weekend I finally had time to clean up the code up for release.



The problem is that while looking for a couple of images for the app I happened to stumble across [Taskbar Meters](https://taskbarmeters.codeplex.com/), which is pretty much the exact same idea I had. Looks like he has made a better job out of it that me too :P

Ah well, I have decided to release my version of the app nonetheless:

[![](/wp-content/uploads/2010/03/ScreenHunter_02-Mar.-14-21.45.gif "ScreenHunter_02 Mar. 14 21.45")](/wp-content/uploads/2010/03/ScreenHunter_02-Mar.-14-21.45.gif)

You can open the app multiple times and set each one to monitor a different value:

[![](/wp-content/uploads/2010/03/ScreenHunter_03-Mar.-14-21.46.gif "ScreenHunter_03 Mar. 14 21.46")](/wp-content/uploads/2010/03/ScreenHunter_03-Mar.-14-21.46.gif)

I have also decided to post the source up on google code: [https://code.google.com/p/win7-taskbar-mon/](https://code.google.com/p/win7-taskbar-mon/)

Anyways you can grab version 0.1 here: [https://win7-taskbar-mon.googlecode.com/files/Windows7_Taskbar_Monitor_v0.1.zip](https://win7-taskbar-mon.googlecode.com/files/Windows7_Taskbar_Monitor_v0.1.zip)