I’m working here in Chrome and Edge on Windows 10 (Dell laptop) displaying a PhotoDome, and I’m seeing very high CPU usage when the browser tab is active (70% of GPU, and the combination of Chrome/Edge and WUDFHost.exe taking up 40-50% of CPU). There’s nothing else going on in the scene.
This isn’t a beefy laptop, but it’s fairly modern – i5 @ 1.6GHz with Intel 620 integrated graphics.
I’ve tried so far (no change for any of these):
Reducing the resolution of the photo used (tried 2k, 3k, 4k, and 8k)
Reducing the radius of the dome
Removed lights
dome.mesh.freezeWorldMatrix()
dome.mesh.doNotSyncBoundingInfo = true
dome.material.freeze()
scene.freezeActiveMeshes()
scene.autoClear = false
scene.autoClearDepthAndStencil = false
scene.blockMaterialDirtyMechanism = true
Anything else I’m missing? Is there a reason why a PhotoDome would be so expensive?
This is a fairly static site – camera doesn’t move, but can spin around, look up and down, etc., and 99% of the time they’ll be looking, not moving. Is there a way to, for example, limit the frame rate or optimize re-renders when nothing has changed.
Since my scene has no animation, I was able to significantly improve the situation by skipping calls to scene.render() when the user hasn’t interacted with the scene within a certain timeframe (using onKeyboardObservable and onPointerObservable to reset that clock).
Thus, when the user is looking around, etc., rendering happens in real-time, but when they’re just looking at the scene without mouse or keyboard activity on the canvas, it only renders about twice a second (which I figure is plenty just in case something else impacts the scene).
Still, this doesn’t answer the underlying question – why is PhotoDome is such an “expensive” activity, and can anything be done to improve its performance?
Yup, no interaction at all with the environment (not even mouseover), just having the browser tab active does it. GPU acceleration is enabled in both browsers, as is WebGL and WebGL2.
The browser sucking up 40% of CPU and 70% of GPU really makes everything else (such as VS Code) feel sluggish, so since my target audience is the general public (who might be on mobile devices or more modest hardware than my work PC), it’s definitely something I’d like to resolve so I don’t have to permanently avoid animation or other things in my scene that might require more continuous frame rates.
I was working on the Playground demo, and figured it out!
I have some HTML elements positioned on top of the <canvas> (for menus, etc.), and a few of them had a CSS translucent background and a blur backdrop-filter.
I wouldn’t think a little blur would be so expensive, but I can probably live without it, unless there’s a trick for doing this that I’m unaware of?
Hi @richardtallent , this is interesting. Were you able to pinpoint whether it was specifically the translucent background or the blur background filter? Or was it both?
I did a little more experimenting, and the fault is definitely with the filter. It drives GPU usage from around 48-50% to around 65-67%. The offending CSS is just backdrop-filter: blur(5px); and only impacts a small navbar hovering over the top of the scene.
-