5 ms·

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

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.

pygy_ 13y ago
The samples work fine is Firefox 22 too (30 to 60 FPS 1.8 GHz Core i5), without the pause you're describing.
- pyalot2 13y ago
  Firefox has been working on an incremental GC
  - mistercow 13y ago
    I believe that they have been using an incremental GC since version 16.
    - kevingadd 13y ago
      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.
- zanny 13y ago
  Firefox on a tf700 dies horribly at around 3 fps. I wonder how webgl will perform on the predominant browser platform - mobile.
- trycatch 13y ago
  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).
dtf 13y ago
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.
- dirkk0 13y ago
  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-8705624 https://github.com/mrdoob/three.js/issues/2435#issuecomment-...
  - deltakosh 13y ago
    The next version (1.2) will remove the pressure on GC by using in place operator and by reusing more entities
    - deleted 13y ago
      [deleted]
- dualogy 13y ago
  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.
kevingadd 13y ago
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.

pygy_ 13y ago

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

pyalot2 13y ago
Firefox has been working on an incremental GC
- mistercow 13y ago
  I believe that they have been using an incremental GC since version 16.
  - kevingadd 13y ago
    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.
zanny 13y ago
Firefox on a tf700 dies horribly at around 3 fps. I wonder how webgl will perform on the predominant browser platform - mobile.
trycatch 13y ago
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).

dtf 13y ago

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.

dirkk0 13y ago
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-8705624 https://github.com/mrdoob/three.js/issues/2435#issuecomment-...
- deltakosh 13y ago
  The next version (1.2) will remove the pressure on GC by using in place operator and by reusing more entities
  - deleted 13y ago
    [deleted]
dualogy 13y ago
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.

kevingadd 13y ago

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.