Why is performance of multiple custom buffer geometries worse in react three fibre (chrome) than vanilla three js?


I recreated this parametric shaping curves example from Matt DesLauriers using the latest version of React Three Fibre. Extracting data from a nonIndexed buffer geometry instead of the old Geometry class and updated it to use GLSL 3. It’s working but the FPS in Chrome is really low on my 2017 Mac Book Pro. It’s performing ok in Safari & Firefox. Matt’s original example works great in all browsers. I created a codesandbox which weirdly performs ok in Chrome until I try and open it in a new window.

Does anyone know why my R3F implementation is slower? I’ve tried all the performance improvements like useMemo and generating geometry globally etc but nothing seems to help.


Are you sure you brought the code over the same way, for instance the cloning of the materials. Did you check if you get the same draw calls, number of geometries and materials? That should quickly point towards the problem.

Fiber doesn’t have overhead, you’re still running a plain requestAnimationFrame loop with nothing else running alongside three. The only difference I can think of is dpr, which defaults to clamp(devicePixelRatio, 1, 2) in fiber, whereas dpr is 1 in default three, so you’d render double the amount of pixels.

1 Like

Thanks for getting back. I’ve double checked all of the above, tried cloning / memoizing the material various different ways, but nothing seems to fix it. Draw calls / No. of Triangles / vertices are the same in both. I also updated Matt’s example to use the latest three just to check but it’s not dropping FPS. Definitely a strange one.

do you have a vanilla codesandbox somewhere?

i’ve ran a cleanup pass, there were a couple of things that i thought were odd. inspecting frames in chrome devtools revealed that threejs wasn’t the only thing active, there was also react-spring, for some reason. also canvas alpha: false is slower than true. there was a file where an old version of fiber was used “react-three-fiber” instead of “@react-three/fiber”

here’s a barebones version Parametric tubes (forked) - CodeSandbox a single frame is 0.25ms on my end, that’s practically nothing, only threejs is there nothing else. but i would need to see the original to have something to compare it against.

Not yet, it’s on my local but i’ll create one. In the meantime there’s this live vanilla version here: http://parametric-curves.surge.sh/

Sorry for needing the clean up, i started that codesandbox from a template and thought those legacy scripts had been removed.

some other observations

vanilla: three 84, 40 drawcalls, 1 geometry
fiber: three 145, 60 drawcalls, 60 geometries

updated the box above to fix the geometry number, it should be comparable unless there are differences between three 84 and 148

Thanks for taking another look at this. That’s actually how i had it initially but refactored it to use the bufferGeometry jsx markup just to see if that would help. Unfortunately it’s still dropping FPS so must be something else.