Will Canvas Render loop affect react component performance?

[brian3814]

Hi I'm totally new to react and r3f, so please bear with my silly question!

I'm loading one gltf model around 40mb while extracting the scene graph and demonstrate with ant design's tree component that has around 12000 nodes as a HUD, and found that the node expansion starts to get laggy. However, with invalidateFrameloop props added to the canvas, the tree component can handle it perfectly. So my questions are:

1. I once read that canvas acts as a boundary to separate react-three-fiber's reconciler from the React default reconciler, does that mean that there are two render loop that are running "asynchronously" behind the scene (useFrame & react's lifecycle)?

2. Most samples i found on codesandbox are pure r3f and has no react components, so is there any best practice to avoid canvas affecting pure react component in my scenario? or is it normal for such file size?

App.js

<Switch>
    <Route />...
    <Route path='/:project' component={(props) => {
        return <View />
    }} /> 
</Switch>

View.js

<div  className='viewContainer' ref={mount}>
    <div className='pageHeader' height={'70px'}>             
        <SettingPanel />
        <Route path={`/:project/:model?/:tag?`} component={(urlParams) => {
            return (
                <React.Fragment>
                    <ModelListPanel  />
                    <ModelsHierarchyPanel />
                    <PropertyPanel  />
                    <DocPanel />
                </React.Fragment>
        )}}/>
                                          
        <ContextMenu />
     
        <div className="canvasContainer">
            <Canvas className='canvas' style={{ background: 'snow', outline: '0', border: 'none' }} concurrent  ref={mount} >
                <ambientLight color="#FFF" intensity={0.5} />
                <ControlLoader  />
            </Canvas>
        </div>            
    </div>
</div>

ControlLoader.js

useFrame(() => {
    controls.current.update();
    controls.current.saveState();
});

return (
    <orbitControls
        ref={controls}
        args={[camera, gl.domElement]}
        enableZoom={true}
        enableRotate={true}
        enablePan={true} />
);

[drcmda]

react-dom does not have a render-loop, only threejs needs that. r3f normally runs like a game 60fps, invalidateFrameloop stops that, so that it only renders when props change which is called rendering on demand. you can mix both the dom and r3f, of course you need to watch a little since if both perform expensive ops it can get narrow. there is a lot you can do to lessen the impact on both sides: invalidateFrameloop, instanced meshes, sharing materials & geometries, etc, and on the dom: virtual lists, concurrent mode, etc.

[brian3814]

Thanks for the quick reply!! Really appreciated!!
Seems like i've misunderstood the term render loop, i think react has lifecycle and r3f has render loop is a more precise narrative.

Yet in my current case, i'm simply loading a single gltf (40Mb in concurrent mode) while hoping to keep the original material (meshStandardMaterial) exported from the source , and using useFrame hook to update my orbitcontroller as shown in the post, so, IMHO, invalidateFrameloop, instanced meshes, sharing materials & geometries might not be what i'm go for?

Given these situations (sorry can't be too detailed since i'm working on a PoC), will you say that the performance of pure react componenent's lifecycle being affected by r3f's render loop is an expected behaviour? Does this indicates that react lifecycle and render loop are running synchronously? If so, what direction should i go to avoid their impact on each other?

Or, under the hood, r3f 's render loop is in fact running asynchronously from react's original render loop, and such performance might resulted from other factors?

[drcmda]

40mb is not healthy in any case, you should compress textures and then run npx gltf-pipeline -i input.gltf -o output.glb --draco.compressionLevel=10 for this you need draco libs in your public folder, like so: https://github.com/drcmda/testlighting

invalidateframeloop is fine, as long as you invalidate it when the user moves controls. use the orbit from drei https://github.com/pmndrs/drei which has invalidate inbuilt

as for avoiding pitfalls https://github.com/pmndrs/react-three-fiber/blob/master/api.md

[brian3814]

I've tried avoiding pitfalls mentioned in the docs yet still encounter the performance problem, i'll try out the texture compressing and the drei orbit solutions and get back if i've worked sth out !!! Thanks for the advice!!

[drcmda]

this article helped me a lot to avoid perf problem on the threejs side: https://discoverthreejs.com/tips-and-tricks on the react side there are myriads of articles available for batching, concurrency, avoiding render. just keep in mind that your perf budget is more or less 16-20ms per frame. if you blow that on either side or both you will face jank.

[brian3814]

For those who have the same issue as mine, I eventually found this post in spectrum and worked like a charm: https://spectrum.chat/react-three-fiber/general/invalidate-globally-except-for-orbitcontrols~27fcebaa-8b3a-43eb-b03d-d788b3b502a1 .