Hacker News Reader

Comment by mistercow | Hacker News Reader

This is really awesome, and it seems like proper WebGL games are going to become a common reality soon.

Chrome handles these samples very well, except for one thing which I think would be a major distraction for games: there's a ~1/sec stutter, which I assume is a GC pause. Google touts their stop-the-world GC as being ultra efficient and accurate, and in many ways it is. But I'm not sure that STW is an appropriate approach for games.

The stutter has improved in recent updates, but it's still there. I wonder if they'll consider an alternative GC approach for situations involving continuous rendering.

View on HN

It seems to be pretty heavy on object allocation, eg:

    BABYLON.Vector3.prototype.add = function (otherVector) {
      return new BABYLON.Vector3(this.x + otherVector.x, this.y + otherVector.y, this.z + otherVector.z);
    };

I do a lot of WebGL work and I'm constantly fretting about avoiding allocations. For instance, compare to gl-matrix's operator:

    vec3.add = function(out, a, b) {
      out[0] = a[0] + b[0];
      out[1] = a[1] + b[1];
      out[2] = a[2] + b[2];
      return out;
    };

A little more awkward, but you're only allocating the vector once and then modifying in place wherever possible. THREE.js takes as similar approach with THREE.Vector3.

Exactly - quote mrdoob: "We try really hard to not create or destroy objects at run time. We use pools and reuse objects as much as possible, or flags. We don't want to rely in the garbage collector." https://github.com/mrdoob/three.js/issues/2435#issuecomment-...

The next version (1.2) will remove the pressure on GC by using in place operator and by reusing more entities

Makes me wonder why this isn't built on top of three.js to begin with?

Three has well over 2 years of rock-solid improvements under its belt, from hardcore graphics programmers to boot.

Three is not a fully fledged game engine, it's "only" providing a reasonably easy to use, sane 3D graphics engine to run on, which raw WebGL is decidedly not.

So any JS "game engine" project would do well to build on three.js (to pick up their many performance and other improvements from the last 2-3 years and those that the community will keep producing over the years to come) and then on top of that provide actual, non-rendering related "game engine" features akin to Unity3D. Objects management, component system, triggers, events, usable input management abstractions, materials management, LOD systems, configurable shadowing/lighting setups (on top of the options provided by three+friends), pluggable post-fx shaders with a few out-of-box ones and easy custom shader integration etc etc etc.

The samples work fine is Firefox 22 too (30 to 60 FPS 1.8 GHz Core i5), without the pause you're describing.

Firefox has been working on an incremental GC

I believe that they have been using an incremental GC since version 16.

Correct. In profiles I typically observe incremental GC running in 1-5ms increments, which makes it easier for it to fit in between frames without causing visible stutter.

Firefox on a tf700 dies horribly at around 3 fps.

I wonder how webgl will perform on the predominant browser platform - mobile.

There are pauses, even worse than in Chrome. Use MemChaser add-on to see GC activity in FF. In Firefox Nightly on the particle demo I have non-incremental 0.6-0.7s pauses every ~10s (not to mention stutter from incremental GC in between the big pauses). In Chrome on the same sample I just don't have any pauses longer than 0.1-0.2s (every ~2s).

I've been pushing for browser vendors to partially mitigate this by scheduling garbage collections during vsync (since the game's requestAnimationFrame code isn't running at that period in time). Unfortunately at present I'm not aware of anyone doing it.

For reference, at 60hz you have roughly 16.6ms to produce a frame and then do whatever you like before it's time to present it. So if the actual game code runs in a few milliseconds (not unreasonable for low to mid tier 3d games, even in the browser), you can do some incremental GC for 5-10ms and not be at risk of missing vsync. It's even better if you do the actual wait-for-vsync in a dedicated thread while you GC; then you won't ever miss vsync, and the vast majority of GC pauses are entirely hidden from the user.

Reply on news.ycombinator.com