• Content Count

  • Joined

  • Last visited

  1. Yea that fixed it, thanks But now I don't know if Three.js got an unfair advantage because the example was inside such a "simple" webpage. I won't be making a full screen game but more of a 3d tool inside a complicated website, so I have more experimenting to do.
  2. Yea that editor is a hog. It knocked about 10% off the CPU, but we're still at about 20% for Three.js and 30% for Babylon.js. And maybe its just a chromebook thing. ( a really ghetto chromebook too ) Looks like what I have to do now is rewrite that babylon.js demo in three (or vice-versa) and see how they compare.
  3. Its a little confusing since I'm using a chromebook. The window manager and desktop manager are also chrome, or something like that. Comparing demos and the top two CPU threads with guessed averages as I stared at htop for about 10 seconds. Maybe its a clue that the second chrome process in both these examples (the 18% and the 23%) have a command line switch "--type gpu-process" and are fairly equal, but the top processes (also chrome) might be the 'window' or 'window render' process. Note that I picked a three.js demo that appears more elaborate. https://threejs.org/examples/#webgl_lights_pointlights 20% CPU 18% CPU https://playground.babylonjs.com/ (basic scene in pulldown) 40% CPU 23% CPU
  4. I'm evaluating webgl frameworks for some projects and I've noticed a much higher CPU load for babylon.js demos than three.js demos, even ones that aren't updating anything! Even the basic scene in the playground is running at 40% CPU, nothing moving, in a hidden tab! (I'm not sure why that's happening, I though requestAnimationFrame was supposed to not run in background, maybe its a chromebook thing.) I can make a few guesses as to why, maybe since babylon.js is a 'game engine' its doing a lot more in the loop, or maybe there's just something wrong with it running on my chromebook. If everything is in fact acting normally maybe its acceptable for this higher load since a game would have the users undivided attention anyway. Does this mean that Babylon.js would be a poor choice for things that run on the 'side', like a graphical tool or demo? Can I trim things out of babylon.js that might be contributing to the load?