Linking components fail due to UI delay between display and action

When working quickly with the mouse, linking components fail. I might try to drop a connection into the upper slot of a component, release the mouse button, then moving the mouse down and the link only takes effect moments after which causes it to link to the lower slot. This delay between visual perception and actual link effect also causes links to fail altogether.
I am a MacOS user, and try to use GH in Mac as much as possible. However, there is a sad gap between GH Mac performance and Apple philosophy of great and smooth UI.

Can you test whether this delay is due to autosaving? You can disable autosaving altogether in the Files section of the Preferences.

Thanks for replying :slight_smile: . I tested it on Mac with your suggestion of turning off AutoSave and it maintains behaviour. Just to check, I tried the same linking operation in Windows and was baffled to be reminded of how snappy the interface feels. I await anxiously for that speed in the Mac version.

Thanks for testing that. It may well have to wait for GH2. Eto is supposed to be a lot better at doing cross-platform-snappy.

1 Like

Hi Pedro-

Ugh. Sounds annoying. I’m not experiencing that sluggishness on my end.

Can you please provide some additional information? Please navigate to Rhinoceros > About Rhinoceros > More info… > Copy to clipboard and paste the content back into a reply here.


Software information

Software versions
Rhinoceros version: 5.4 WIP (5E334w)
Rhinoceros path: /Applications/
IronPython version: 5.1.2015.131
WIP expiration: 19 January 2018
Language: en-PT (MacOS default)
macOS version: Version 10.13 (Build 17A405)


Third party kernel extensions
com.Cycling74.driver.Soundflower (101.6.7) 552035F3-D37B-33A2-8D01-3557E84EF982
org.pqrs.driver.Karabiner (10.21.0) 0857A9A2-EC66-3C69-8403-2C21B732C140
org.virtualbox.kext.VBoxDrv (5.1.30) 84DA15FE-3565-342D-99EA-5DB4BE28B54F
org.virtualbox.kext.VBoxUSB (5.1.30) BDD590D1-3A93-34A8-BF61-4A2A83487149
org.virtualbox.kext.VBoxNetFlt (5.1.30) BA7273E5-779A-3246-A2B5-220DAD7B95C6
org.virtualbox.kext.VBoxNetAdp (5.1.30) CBDE5D9F-0224-3A7E-9443-E8939BB79CB4

Hardware information

Computer hardware
Hardware model: MacBookAir7,2
Processor: Intel Core i7-5650U CPU @ 2.20GHz
Memory: 8 GB
Architecture: Intel 64 bit

Video hardware
Graphics: Intel HD Graphics 6000 1536 MB
Memory: 1536 MB
Screen size: 1440 x 900
Displays: Color LCD (126dpi 1x)

USB devices
Apple Inc.: Bluetooth USB Host Controller
Apple Inc.: iPhone

Bluetooth devices
Apple: Apple Wireless Mouse

OpenGL information

OpenGL software
OpenGL version: 2.1 INTEL-10.28.26
Render version: 2.1
Shading language: 1.20
Maximum texture size: 16384 x 16384
Z-buffer depth: 24 bits
Maximum viewport size: 16384 x 16384

Implementation settings
Use texture compression: No

Appearance settings
Antialiasing: 4x
Mip map filtering: None
Anisotropic filtering: None

Thanks Pedro. Let me see if I can find a similar MacBook Air around here and see if I can see what you mean.

Hi @Pedro_Varela

While I try to find a similar machine to test on, could you please try a couple things for me?

First, you might want to update your macOS High Sierra to the latest version (10.13.2). There are lots of good reasons to do this - this is the best one - but we’d need you to update to something we can install.

Second, can you please try starting your MacBook Air in Safe Mode and testing the performance of creating links in Grasshopper? You have a couple third-party kernel extensions that I’d like to subtract from problem to see if they are impacting performance or not.

One other question: What is the en-PT language? (I didn’t know this language existed. Is this the Portuguese spoken in and around Providence, RI?) But seriously, what is your macOS language? What is your Rhino language? I doubt this is related, I’m just curious.

a) I updated to 10.13.2 (had to use this URL as the App Store had an error). This seems to have improved the performance quite a bit. I hope it wasn’t just a matter of restarting.

b) Safe mode seems to not have made such a big impact.

c) My OS is in English, but I live in Portugal. I also have an US keyboard…

Thanks for updating macOS, restarting, and testing out Safe Mode. It sounds like the performance is significantly better (?).

I have access to an “older” MacBook Air (MacBookAir6,2; whereas you have the MacBookAir7,2). I should be able to test this out tomorrow to see if I can discern a difference. (Everything is really snappy on my machine…but that’s not saying much).

I feel that “snappiness” is very relative to the .gh file size and general astronomical mood. Whereas in the Windows version is not: WinGH is very solidly fast and snappy. {I know we’ll get there! :slight_smile: )

I just tested wire snapping on a 2013 MacBook Air with a relatively large .gh file and it all felt snappy to me. If you have a sample definition that exhibits this sluggish snap, please send it over.

As soon as I experience sluggishness, I’ll send that file.

1 Like