We believe you are seeing this problem. The video does not help us recreate the same problem here. That’s the key to finding it and fixing it.
No.Rhino is distributes as a DMG so there’s nothing outside of the PLIST that changes or can be deleted.
Do you have V5 on this computer?
If so, is it 5.5.5?
Shortly before V6 was released, we needed to do a fix for V5 so they could both share the same PLIST.
If you aren’t running V5.5.5 that could be involved.
Make sure if V5 is installed, it’s 5.5.5
If it’s not, update it and reset your PLIST so V5 and V6 can share the same one without serious problems…
All I can tell you is Windows does this much faster than Mac does, but I’m not seeing the slow response you are in Mac.
Do you have other files open, or other applications running?
This issue has been bothering us for some time. Unfortunately, it’s one of those ones that is difficult-to reproduce-on-our-computers type of issue, so we end up searching for code that might be responsible, which is less-than-ideal from a developer standpoint. That said, we think we found a likely culprit and we might have fixed in the latest RhinoWIP. It would be really helpful if those of you who are experiencing this lag would test it out and see if we’ve made a difference.
We believe we can safely cherry-pick this fix back into our Rhino 6 product, but we’re going to put it into the branch that corresponds to the 6.29 Service Release for stabilization protocol reasons. That way we have some safety-net to make sure we haven’t caused major regressions with this fix. The Release Candidate for 6.29 is not out yet, but should be in the next couple of weeks. I’ll chime back in here once it’s available so you can test again in Rhino 6 for Mac.
Good news. We managed to back-port this (safely, we hope ) to Rhino 6. Thanks again for testing this in Rhino 7, but it would also be helpful to test it in the latest Release Candidate for Rhino 6 as well. Does it work there too?