High CPU Utilization #1
Comments
|
I just tried 5 different WebGL/Three.js demos around the web in Google Chrome and all ran my CPU up to 80% to 100% utilization. They all also caused lag with other apps on my system. I think I did this test before and it's what convinced me to set this project aside. |
|
When running this app with $ uname -a
Linux askella 4.13.0-26-generic #29~16.04.2-Ubuntu SMP Tue Jan 9 22:00:44 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
$ npm start
> cadquery-gui@0.1.0 start /home/nymphii/temp/cadquery-gui
> electron main.js
Electron could not be found. No hard resets for you!I can observe:
When I pan/zoom/rotate the resource usage doesn't change at all.
Although the CPU usage is high, it still seems like a plausible implementation (with a few kinks to work out). Could this problem be isolated to your system? |
|
It could, but I've had the issue on 2 very different systems. The only common thread I can think of is that they're both running Ubuntu. 33% on 3 cores still seems like a lot for an app at idle. If it was set to only render on mouse drag or something that might take care of that I guess. |
|
I agree, it's a bit heavy, especially while it's doing nothing. |
|
I do believe it's re-rendering even when nothing is moving. I'm not well versed in 3D things though, so I'm not totally sure what should be happening. I tried this CSG demo and it runs multiple cores at 30% to 40%, spiking to 50%+ sometimes. https://stemkoski.github.io/Three.js/CSG.html I also tried this minimal example to make sure I wasn't doing anything wrong in mviewer.js. It runs my CPU at round 50% utilization. <html>
<head>
<title>My first Three.js app</title>
<style>canvas { width: 100%; height: 100% }</style>
</head>
<body>
<script src="js/three.min.js"></script>
<script>
var scene = new THREE.Scene();
var camera = new THREE.PerspectiveCamera(75, window.innerWidth/window.innerHeight, 1, 10000);
var renderer = new THREE.WebGLRenderer();
renderer.setSize(window.innerWidth, window.innerHeight);
document.body.appendChild(renderer.domElement);
var geometry = new THREE.BoxGeometry(700, 700, 700, 10, 10, 10);
var material = new THREE.MeshBasicMaterial({color: 0xfffff, wireframe: true});
var cube = new THREE.Mesh(geometry, material);
scene.add(cube);
camera.position.z = 1000;
function render() {
requestAnimationFrame(render);
cube.rotation.x += 0.01;
cube.rotation.y += 0.01;
renderer.render(scene, camera);
};
render();
</script>
</body>
</html> |
|
Looks like there are tools like WebGL Inspector. The Google Electric Flower demo linked on the WebGL Inspector page runs my CPU really hard. I would assume that's as optimized as you can get too. |
|
Ok, there's discussion related to this here One of the users posted this fiddle for rendering static scenes, which works great for me. I think it acts how we need it to. |
|
I just created a 'viewer' branch with a minimal start on re-implementing mviewer. The scene is static and I have to re-implement (or port over) all the functionality of mviewer, but it shows a static object now and the CPU utilization acts as expected (it's low until you start rotating the object). The rotation is smooth and the app doesn't cause other apps on my system to lag. I'll use that as the base to create a new viewer that's usable. |
|
Created #5 address this. I feel we've sufficiently addressed this issue. @fragmuffin feel free to reopen if you still see a problem. |
Any kind of rendering (main scene and origin scene) causes high CPU utilization. Here's my processor info. I'm not running a weak CPU/GPU setup by any means.
i7-7600U CPU @ 2.80GHz
NVIDIA Corporation GM108M [GeForce 940MX] (rev a2)
If I comment out the these two lines of code so that nothing is rendered, the CPU utilization drops from about 40% to 60% at idle (spiking to over 100% when actively rotating) , to about 6%. Disabling anti-aliasing and other things that I've tried have had no effect. I've tried just rendering the main scene, and then just rendering the origin scene. Both lead to the same high CPU utilization problem.
Tagging @fragmuffin on this since I've cited it as the main barrier to moving forward with this GUI.
The text was updated successfully, but these errors were encountered: