V8 is slower than V7?

can you give us details of the screen? Is it an 8k monitor or something like that? Does it have any scaling applied in windows? Is it vastly different resolution than the other screens?

have you tried changing the output the port it uses?


The screen is a 2018 34” LG ultrawide curved monitor (34C899-W), plugged in with a USB-C chord, and the resolution is lower than 4k with no odd scaling.

Im using it with a Dell dock station, which I suspected was the problem, but I plugged it directly to my machine and it has the same issue.

For troubleshooting purposes can you close Rhino. Disable the Intel, restart Rhino instances and give it a go again?


Even worse:

@Santiago_Serna the only way to test your display is to do that with a model that is not affected by the logged bug. Also, the view and viewport size need to stay the same across all tests.

@Gijs, could you provide a model that will work?

what do you see here in tools>options>view>display modes>open gl

1 Like

I have also huge performance issue in a relative large file on rhino 8.

I have made this file with the wip version of rhino 8 last September.
Then it used to work like a charm.
It was much much faster than rhino 7 at that time.
So i was thinking it was a latest release rhino 8 problem.
Last month i bought a new laptop with lower specs than my pc. I open the model there and again it works perfectly.
So i suppose its a system problem caused between September and now. I believe the solution is a fresh windows install. Maybe that’s the problem here. I don’t have the time right now for this, and i don’t work on such a big project. When i reformat my pc i will report if the speed is back.

1 Like

Something to note to all here…

We (the developers) ran into an issue on some of our development machines a while back, where Rhino would get bogged down during debug sessions, and even the keyboard would become almost non-responsive…it was quite frustrating for some of us and a huge time and workflow suck. Since this seemed isolated to only a handful of devs, we just figured something was “off” with their configs.

We discovered that something in Rhino’s “Settings” environment/folders was somehow the cause. By deleting the entire Rhino settings folder in the AppData storage point, the problem was somehow eliminated. One of the devs tried to isolate the culprit by performing periodic differences between settings that worked vs. settings that did not (Note: His system seemed to be the only one where the problem returned after a while once the settings were deleted). Unfortunately he was not able to come up with any definitive conclusion. It was mentioned that somehow the OSnap and Filters panels were involved in some way, but again, nothing definitive, but it did/does seem related to which panels were opened and if they’re docked or not. I know that sounds odd and even strange…but all kinds of events can fire and get processed behind the scenes in ways that are not obvious to the onlooker.


  1. What causes this? We don’t know
  2. Why does this happen on some machines and not others? We don’t know
  3. Deleting the settings folder seems to clear things up? Yes, for most…but sometimes the problem returns.

Why am I even mentioning this? Because (IMO) the problem discussed in this thread seems to also be configuration dependent (i.e. Santiago’s model is 2x to 3x faster in V8 than V7 here on my machine), and given Ar00302’s recent post, I started to think about the issue I described above.

So before anyone goes off and reformats their hard drive and reinstalls Windows…You might try deleting Rhino V8’s settings folder entirely (don’t try to save stuff off in hopes you can then make a partial recovery), just delete the entire folder. I realize that’s pretty destructive, and it’s certainly not a solution…it’s more of a diagnostic step to see if it’s related to the above and a “What happens next” type of thing.

The folder I’m referring to is this one:


Note: If you don’t want to nuke your current settings, then you can try creating another Windows account on your computer, login to that account and see if Rhino runs any faster… If it doesn’t, then I’m pretty sure the problem is unrelated. If Rhino does run faster under the new account, then I think we might be on to something.

Note2: If you do try the new account method, do not setup all your toolbars and panels before testing…just start Rhino in its default layout settings, and see how things run.

Edit: Before nuking anything, please make a backup of the entire 8.0 folder… So that if this test doesn’t reveal anything, you can just copy the backup to get back to what you had prior.



Note to anyone who has significantly customized their toolbars/libraries, whether they be the default one or an added .rui or both… As much of the info on toolbar mods is now stored in various settings files, nuking the entire folder will pretty much nuke your entire UI setup including toolbars.

I realize that…which is why I want to be sure people know this is NOT a solution.


@jeff I’ll keep this method in as a workaround for other issues. Unfortunately, it didn’t work for me today.

@jeff i tried both methods mentioned above.
Deleting rhino 8.0 folder, doesn’t make any difference in my system.
Creating a new account makes a huge difference. The model is now responsive.
But still i don’t have either the September or laptop speed. I am able to navigate the model where in my primary account the model responds after two seconds of every mouse movement.

I’m reviving this thread.

It seems that the latest update significantly improved display performance (still slower than V7), but the new features have improved my workflow overall. However, I am running a Grasshopper definition that used to work fine in V7 but is now severely slow in V8. More so, just having Grasshopper open (with the solver locked) makes the GUI very slow in any kind of 3D view forcing me to restart Rhino (“closing” GH doesn’t do anything) to regain an acceptable level of performance.

Is anything being done to fix this?

Hi Santiago,

There are a lot of variables that can affect performance in such a workflow.

Can you provide detailed information of the issue in a way we can repeat? Thanks


1 Like