BUG? - Grasshopper Solve - Much Slower In Rendered Display Mode


I found a weird bug or at least unexpected performance behavior.

It appears that when the Rhino viewport Display Mode is set to Rendered, the Content Cache in Grasshopper updates the cache significantly slower than when in Wireframe display mode.

I couldn’t figure out why my script was solving at 3 seconds plus when my “heaviest” component was profiling at 320ms and nothing else came close.

Perhaps this is due to how Model Materials are being processed on the Cache? I’m not sure but you can see the difference in the video below where I move a point that creates a door for testing.

Rendered Display Mode = ~3 seconds script solve
Wireframe Display Mode = <1 second script solve (almost instant)

I’m working on a large grasshopper definition so it’s possible this isn’t noticeable on a simple definition but I’ll test and check.

@kike @AndyPayne @wim

Do you see a Content Cache performance difference on your end between the Rhino Display Modes?

Thank you all!

Kindly bumping this to see if anyone can repeat on their end?

1 Like

Hi Michael, in a small test i’m not seeing any difference, a few variables that could affect the solution though, can you post a small example showing the behavior? Thanks

1 Like

Thanks for checking @Japhy , I’ll try and post the smallest example showcasing the behavior in a moment.


I cannot seem to reproduce it in a simple/paired down definition.

The definition I’m having issues with is a very large one with 20+ query and cache components, chained dependencies and so on. I guess I will keep testing in that and see if I can solve where the roadblock is occurring more specifically.

I’ll report back if I have more information

1 Like

Hey. This might be unrelated, but I am experiencing a strange similar behavior, but within Grasshopper. Large script, many dependencies, however just little referenced geometry.

Grasshopper lags each time:

  1. When a new wire is connected to a component (even without doing something)

  2. When a number slider value is changed (on a previously intact slider)

  • When running on Rhino 7, the lag is still present, but not that hard.
  • When small files / fresh files are okay.

This bug literally kills my productivity. What do you think, @Japhy, could this relate to this topic as well? I cannot share the file.

Rhino 8 SR6 2024-3-26 (Rhino 8, 8.6.24086.11001, Git hash:master @ 8e3b686f596bb6443e56e6dbecf0f54f4888713a)
License type: Commercial, build 2024-03-26
License details: Cloud Zoo

Windows 11 (10.0.22631 SR0.0) or greater (Physical RAM: 63GB)
.NET Framework 4.8.9181.0

Computer platform: DESKTOP

Standard graphics configuration.
Primary display and OpenGL: NVIDIA GeForce RTX 3090 (NVidia) Memory: 24GB, Driver date: 3-12-2024 (M-D-Y). OpenGL Ver: 4.6.0 NVIDIA 551.86
> Accelerated graphics device with 4 adapter port(s)
- Windows Main Display attached to adapter port #0
- Secondary monitor attached to adapter port #1

Secondary graphics devices.
AMD Radeon™ Graphics (AMD) Memory: 1GB, Driver date: 1-2-2024 (M-D-Y).
> Accelerated graphics device with 5 adapter port(s)
- There are no monitors attached to this device!

OpenGL Settings
Safe mode: Off
Use accelerated hardware modes: On
Redraw scene when viewports are exposed: On
Graphics level being used: OpenGL 4.6 (primary GPU’s maximum)

Anti-alias mode: 4x
Mip Map Filtering: Linear
Anisotropic Filtering Mode: High

Vendor Name: NVIDIA Corporation
Render version: 4.6
Shading Language: 4.60 NVIDIA
Driver Date: 3-12-2024
Driver Version:
Maximum Texture size: 32768 x 32768
Z-Buffer depth: 24 bits
Maximum Viewport size: 32768 x 32768
Total Video Memory: 24 GB

Rhino plugins that do not ship with Rhino
C:\Users\PC\AppData\Roaming\McNeel\Rhinoceros\packages\8.0\NVIDIADenoiser\0.4.3\NVIDIADenoiser.Windows.rhp “NVIDIADenoiser.Windows”
C:\ProgramData\McNeel\Rhinoceros\7.0\Plug-ins\Datasmith Rhino Exporter (d1fdc795-b334-4933-b680-088119cdc6bb)\DatasmithRhino7.rhp “Datasmith Exporter”

Rhino plugins that ship with Rhino
C:\Program Files\Rhino 8\Plug-ins\Commands.rhp “Commands” 8.6.24086.11001
C:\Program Files\Rhino 8\Plug-ins\rdk.rhp “Renderer Development Kit”
C:\Program Files\Rhino 8\Plug-ins\RhinoRenderCycles.rhp “Rhino Render” 8.6.24086.11001
C:\Program Files\Rhino 8\Plug-ins\RhinoRender.rhp “Legacy Rhino Render”
C:\Program Files\Rhino 8\Plug-ins\rdk_etoui.rhp “RDK_EtoUI” 8.6.24086.11001
C:\Program Files\Rhino 8\Plug-ins\NamedSnapshots.rhp “Snapshots”
C:\Program Files\Rhino 8\Plug-ins\MeshCommands.rhp “MeshCommands” 8.6.24086.11001
C:\Program Files\Rhino 8\Plug-ins\IronPython\RhinoDLR_Python.rhp “IronPython” 8.6.24086.11001
C:\Program Files\Rhino 8\Plug-ins\RhinoCycles.rhp “RhinoCycles” 8.6.24086.11001
C:\Program Files\Rhino 8\Plug-ins\Grasshopper\GrasshopperPlugin.rhp “Grasshopper” 8.6.24086.11001
C:\Program Files\Rhino 8\Plug-ins\Toolbars\Toolbars.rhp “Toolbars” 8.6.24086.11001
C:\Program Files\Rhino 8\Plug-ins\3dxrhino.rhp “3Dconnexion 3D Mouse”
C:\Program Files\Rhino 8\Plug-ins\Displacement.rhp “Displacement”
C:\Program Files\Rhino 8\Plug-ins\SectionTools.rhp “SectionTools”

On large grasshopper definitions/projects you may experience this due to the GH autosave. Is this enabled for you?

Get here by going to File>Preferences>Files


Interesting, I hadn’t considered this. I’ll test, thanks

That was actually both. “On object changed” and “On wire”. Wow, thank you! That solved the issue. As this is probably not related to the original topic, I suggest to move it somewhere else.

That’s good to know though, I had no idea about that and am also working a large definition and that helped a lot. It didn’t solve the topic of this post but it made working in the canvas space less painful sometimes, thank you.

Is it possible that when in rendered mode, the material table is being written to in a different manner than when in wireframe mode? If there are more lookups or loops happening related to materials perhaps that’s the hiccup.

And in wireframe mode it can ignore these until the viewport is set to rendered, at which time it makes the calls but they are not occurring/conflicting at the same time as the GH script solve…

Just speculation ^ still trying to pinpoint the behavior… Thanks!