As this might be the case, it’s not exactly the whole truth in my opinion, since I have MacBook Pro with hi-def display, but I mostly work in clamshell mode (closed lid) with a bigger, external monitor that doesn’t have a “super crazy” resolution (2560 x 1440) for its overall size. Still the issues are nearly the same as working with the laptop display, maybe a tiny, tiny bit less. Also do most Windows users really work on low-def displays nowadays?
It’s funny, nearly ironic, how the .Net framework always comes up, when it comes to cross-platform issues.
Though I’m interested in this kinda stuff and appreciate @dan’s honesty, I feel like most of customers really shouldn’t have to care about how it’s difficult for you guys to emulate or port this and that to macOS. I mean you kinda promised to deliver a finished product for professionals on the mac platform, but it often feels like we’re still in the beta phase! Let’s be honest there are still tons of bugs, and it’s super tiring and time consuming to report them, wait for answer (that may never come), wait for the next update, etc.
Because of you, I never stray too far from the sidewalk, erm… origin, I mean, origin! I hope I don’t get a copyright strike for this.
When I read all of this I’m not exactly optimistic for the futur of macOS Rhino and especially Grasshopper. At this point, it’s simply not a great tool performance-wise especially for professional users, simply because of these limitations. A friend of mine uses an iMac Pro, which is a ludicrously fast (and expensive) machine and most issues still persist (unfortunately he’s no active forum member), but it does have a 5K display.
When I look at other similar programs that I’m familiar with, like Houdini, I’m sorry to say, but the UI experience is much better and more fluent even with huge, nested definitions (much like clusters in clusters) and frankly the indie license is very affordable.
I have suggestion for you, drop four or five components onto the canvas and try to resize the Grasshopper window on macOS!
Like @rudolf.neumerkel already reported, it’s not really hard to come up with a laggy definition.
It’s really like working in slow motion! Bullet time!!
I have found a workaround though! If you do everything in a scripting component (i.e. Python, C#), you can really save up on components and only have to deal with all the other issues.
Other tricks that can speed things up for large definitions:
- no Scribbles
- no grouping
- no use of excessive panels that output lots of data
- use Data Dam components
Also, Rhino must have a much more solid backend, because its window behaves much more fluently!
Edit (2020-06-12)
What I forgot to mention yesterday is that the overall performance of Grasshopper in Rhino 5 was better.