Major performance issues in V6

Thanks for the system info Robin. There’s only one GPU in your Mac and it’s not that powerful, my first thought is to disconnect the second Dell 27 inch display as a test. Any difference in overall performance? The disabling of the skylight in the Rendering panel should also make the Rendered display mode similar to v5 for you.

Robin is correct, you can’t get the 6.17 service release candidate in the beta you still have. You’d have to download an evaluation of Rhino 6 for Mac in order to have access to 6.17. If you haven’t used a Rhino 6 evaluation on Windows before this will get you another 90 days without buying a license.

1 Like

Hi Brian

Thanks, but I rarely use the render viewport setting. At the moment I’m just copying and pasting a small object from from one file to the the main one I’m working on and I’m treated to beach balling and a long period of completely unresponsive rhino.

It is really tiresome.

The comparison is with V5 which seems to be incredibly smooth and fast.

Did disconnecting your second monitor make a difference?

In order to test out the 6.17 Release Candidate, you need to be running Rhino 6 for Mac 6.16. You can run Rhino 6 for Mac 6.16 by:

  1. Evaluating an RH60 license (if you have not done so already; you may have if you have evaluated Rhino 6 for Windows).
  2. Purchasing a license.

Take note: we hope to “graduate” the 6.17 Release Candidate into a full-fledged Service Release sometime soon (no promises as to when, though, but the hope is soon).

Ok Dan. Thank you


Hi Brian

I’ve been testing with the external monitor not attached due to the other issue I was having as noted in the discussion with @John_Brock about by layer or by object material settings.

Anyway, as you might expect certain things are definitely a bit quicker without the external monitor. Somethings are still slow as molasses.

Things that are better than before:

  • Material panel
  • General viewport performance (still way less smooth than V5 even with the external monitor attached)
  • OBJ import seems a bit better (speed and reliability)

Things that are still painfully slow during this short test:

  • Copying and pasting a fairly small file into another
  • Changing the viewport from raytrace to any other viewport setting (or pausing raytrace)
  • Closing a file and choosing to ‘revert’ changes (beach ball bonanza)
  • Named views panel


Thanks for trying that Robin. For general veiwport perfomance, make sure that the display mode settings in Rhino 6 match what is being used in Rhino 5 as that version couldn’t do the same things in the display.

I’d agree with John B. that having you test 6.17 when you can is the best way to see if things have improved on a Mac like yours. My only other suggestions regarding what is slow still without trying to run an external monitor, would be to check that the named views are not using Raytraced or Rendered modes as those will take more system resources. If you do use Rendered mode in any of them, make sure the settings are the same as those in Rhino 5 for a better comparison.

If you can post any small file that takes longer to copy and paste from Rhino 6 than it did from Rhino 5, please do so. I’ll need to reproduce that here for a bug report. Please indicate the exact steps such as if you are pasting to/from Rhino 5 or Rhino 6 and what objects are being selected.

Raytraced uses a lot of system resources and was not available in Rhino 5 as you know. I can see that causing a delay on a system like yours which would only be able to utilize the CPU. The model size, lighting and materials as well as whether you are in a maximized view are also factors.

Waiting for ‘revert changes’ would be another one I’d want to see a file and specific steps for if possible. I’d need to reproduce it here for a report knowing exactly what was done in the file before deciding to close and revert those changes. One idea is to also check if the file was opened off of a network or cloud storage drive as that would be a factor too in any latency.

Hi @BrianJ

Re the performance problems when choosing to revert the file, I just don’t get why this is a performance issue at all. Rhino doesn’t need to do anything other than to NOT save changes.

We already know that autosave is not supported on NAS drives. I have checked the box to not be asked about it every time so I can’t recall the exact wording.

What is Rhino doing to these files for it to take so long to close?

Could it be linked to the save only file issue people are having when working on remote files? See here: Read-only file


I’m not sure what happens in the code when choosing Revert. I can still try to reproduce the delay here if you can provide a file. Email if it can’t be posted publicly or use Rhino - Upload to Support and explain the steps to take in the comments.

@dan FYI in case you have more info on what Revert does.