I’m currently migrating to make use of the Viewer V2 Alpha and want to deactivate and reactivate the render-loop for performance. It’s a responsive page too where the canvas relies on a parent node’s calculated dimensions. There’s also a resize observer to manually re-render while the canvas is not focused. The canvas only renders on focus other than that.
I’ve tried to suspend and reactivate the default render loop using suspendRendering. It almost looks like it can be reactivated but looking at the code it gets disposed along with the controller. Is there a good reason why suspendRendering is provided as an initializer prop?
Currently I have this to re-add a new render loop (I can’t use the original fn as it is destructive):
if (viewerDetails.scene.getEngine().activeRenderLoops.length === 0) {
viewerDetails.scene.getEngine().runRenderLoop(() => {
viewerDetails.scene.render();
// other stuff omitted...
});
}
The issue is I would have to replicate the code in render too. If you agree, as a feature-request could we have an invoker to re-add the internal render loop please?
@ryantrem you should be able to understand my mumbling (hopefully) without a CodePen but let me know if you’d like one. I appreciate this may be a wont-fix issue but can see other requests in future. I think performance is a key consideration here as we don’t want unnecessary rendering?
If I’m understanding correctly, you want to suspend the render loop when the viewer does not have
focus. If that’s right, you can definitely do that today. Here is an example:
I got tosuspendRendering() but didn’t realise it returned a token/must use with dispose(). Thank you for taking the time, I’m sure this will make its way into the examples. Great news with the further optimisations! It all helps with use of multiple canvases.
Just to note - I have also observed your issue #2 on PR 15864 when using WebGPU. I believed it had something to do with React but it may just be the nature of latent events. See the following CodePen repo: https://codepen.io/j-te/pen/pvzOgqx. It errors on window resize (keeping in mind CodePen uses an iframe). Chrome 131.0.6778.266
logger.js:52 BJS - [11:30:25]: WebGPU uncaptured error (20): [object GPUValidationError] - Destroyed texture [Texture "D3DImageBacking_D3DSharedImage_SharedImagePoolBase_Pid:19232"] used in a submit.
- While calling [Queue].Submit([[CommandBuffer from CommandEncoder "upload"], [CommandBuffer from CommandEncoder "render"]])
Thanks for sharing these findings and providing the codepen! It’s strange that this does not repro in the Viewer test app, but repros in the codepen. It does repro for me 100% of the time though, so hopefully that makes it easy to investigate. Will update this thread with more findings…
With WebGPU, all rendering code must be done within a pair of engine.beginFrame() / engine.endFrame() calls, which correctly set up the rendering context (you should also do this in WebGL, but there will be no crash if you don’t, as no critical code is executed in these functions in this case) :
However, I’m not sure why there’s an onResize handler in the first place, it seems it’s not needed?
It also shows context to why I’m using resize. I want the canvas to re-render if unfocused, after/during resize to keep it looking responsive. There’s bubbling to consider but not been put into this example.
Unrelated observations:
Embedding the Viewer iniframe considerably affects the performance with WebGPU (understandably).
Embedding the Viewer in iframe produces the warning: BJS - [14:52:10]: Ray needs to be imported before as it contains a side-effect required by your code (see iframe branch).
Do you see this behavior in CodePen (since it uses iFrame)? Do you have a repro you can link? I didn’t see any errors about Ray in the console in CodePen.
Amazing work! I have already updated my project and will report back if any issues are found.
I dug a bit deeper and I used version viewer@7.38.0-alpha (I probably copied this version from docs early on). Here’s a CodePen where you have to pick to repro:
The issue has gone away since version 7.44.0 so should be all good. I’m guessing it may have been an import syntax error.
@ryantrem very minor recent observations (more for others):
Upgrading from ^7.47.1 to ^7.49.0 I had to delete package-lock.json due to a typescript error with the AssetContainer. It is maybe down to a combination of my project using React 18.2 and core BabylonJS peer dependencies.
Sometime after ^7.47.1 I noticed the scene background started showing the default dark blue background after init so I had to add this to fix:
viewerDetails.scene.clearColor = null as any;
Not the most elegant solution but Color4 class isn’t a named export.
Very impressed with the updates and your Viewer implementation is serving really well with low code efforts.
For this project I have only ever had @babylonjs/viewer as a project dependency: on 2 machines I encountered this. Nothing BabylonJS ever installed globally either.
Lower: createViewerForCanvas().
This is the package-lock.json blame additions when I upgraded from ^7.44.0 > ^7.47.1 which reveals a bit more with the peerDependencies…
Update on dependency mayhem: after trying to update ^7.51.2 > ^7.51.3, npm thinks the correct version is installed but isn’t…
react-scripts may be causing sub-dependencies to not install properly which may result in older versions being retained. May have something to do with critical fixes. As this is an older project I’ve been putting-off ejecting, but will probably now and move to Vite (create-react-app sucks when your app matures).
.