As David wrote in that thread that I referred to:
Please consider breaking up huge files into smaller part, either using a nested approach with clusters or a sequential approach with the data input and output components.
So, yes.
-wim
As David wrote in that thread that I referred to:
Please consider breaking up huge files into smaller part, either using a nested approach with clusters or a sequential approach with the data input and output components.
So, yes.
-wim
Hi! Thanks to you and David. I tried to pack two major parts into clusters individually, as screenshot below:
Iāve also encountered this issue, originally described by @Pedro_Varela. Is there any known solution to this? My grasshopper interface lags tremendously on my Mac.
My theory is that the Scribbles and groups tremendously slow down sizeable definitions on macOS.
I just tried removing all groups and scribbles from my grasshopper file, without any noticeable increase in performance. Any other ideas of might cause this?
I havenāt read this whole thread but have observed that geometry far from the origin causes GH to slow WAY DOWN, including any attempts to move around the canvas.
I am also not that happy with the current gh-canvas responsiveness⦠In some areas it is really painfully slow. From my experience, the canvas framerate is a function of the following main parameters:
I actually opted for a 1440p external monitor, and scaled the GH window down a bit, so that I have a lower canvas resolution, which in my experience is the main factor for the framerate.
That said, I think the current performance of the canvas UI is not acceptable. Even resizing an EMPTY GH window takes ages.
Dan has already posted some potential suggestions to solve this:
Hope the GH canvas will run smoothly on the Mac one day, since it very important for creating large scripts and navigating through them in a fast manner.
Hope this was helpful!
I think your contribution is most valuable. Most of all, your three āparametersā seem to me very well described, as I also feel exactly the same symptoms in my system. I will not get tired of claiming how unacceptable this UI performance is. I should confess that I did not upgrade from Rhino 5 to Rhino 6 because I donāt feel good shelling out money for a software which is not in the level it claims to be and should be. (and I tested the beta versions).
Hey everyone,
Thanks for the additional information, and Iām sorry to hear there are still lots of frustration with this. The biggest performance factor that Iāve experienced is the size of the canvas, which is exacerbated by retina displays. As you all may understand, it is very difficult to translate the windows-specific System.Drawing infrastructure that Grasshopper uses to CoreGraphics in an efficient way. However, as @Joseph_Oster reports there may be some issues drawing some things āfar from originā, which might be able to be improved/optimized.
What would really help troubleshoot this issue on our end is sample GH definition(s) that exhibit extreme slowdowns of canvas drawing that you are encountering. If any of the definitions youāre working with are extremely slow, feel free to post them here or send them to me directly and I can look to see if I can find anywhere we can improve.
Thank you for you answer!
From my experience this behavior is reproducible with nearly any GH definition, that has 10-20 components.
May be the case⦠for me it seems that very large scripts slow down the canvas even further (more than 1000-1500 componentsā¦)
I attached a video showing the canvas performance first with a script containing 105 components and secondly a script with 1625 components.
With the latter, it performed equally to a 100 component script, but abruptly got slower after containing around 1400 components. I cannot share the latter script since this is from a competition we are working on, but ill try to find another large scriptā¦
Finally I am resizing an empty GH window, which takes very long (I am using a base model 16"MBP).
Thanks a lot and please let me know if anything is unclear!
Rudi
Hey @curtisw,
the last few bigger scripts that I did, where for work, but I found an older one that exhibits the same issue. I did some comparisons with Windows on BootCamp, where I got 42fps
(of course depending on where you zoom in at the script). On the Mac side, I canāt give an exact fps
count as the Canvas redraw speed
does not give accurate results (I got sth around 92fps, which is not correct). But on GH for Mac the canvas is extremely slow, no matter where you zoom in in the script. Even if you just zoom into an empty area (!).
I attached the script, it is a bit messy, but hope it helps
Best wishes from Vienna!
Rudi
Studio_HB_Skript.gh (1.1 MB)
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:
Also, Rhino must have a much more solid backend, because its window behaves much more fluently!
What I forgot to mention yesterday is that the overall performance of Grasshopper in Rhino 5 was better.
Here is another example with a relatively small script (300 components), but āhigher component densityā, which is also quite laggy to move through⦠This is now filling half of my MBP16" screen. Having gh in full screen mode would be even slower - however having a dual screen setup with Rhino on one screen and GH on the other is very commonā¦
Hope the frame-drop is visible in this low quality video.
Best wishes,
Rudi
200525_aggregation and export_MV.gh (139.9 KB)
I just wanted to chime in here and mention that I tested @curtiswās performance improvements and they appear to give a major boost to Grasshopper on Mac. Curtis has done an amazing job with this and we hope you test out the the Release Candidate and report back.
Previously, the FPS counter found in View > Canvas redraw speed was broken, but Curtis has fixed that too in this update. That means that, going forward, we can make more meaningful comparisons to see if weāve improved or regressed.
@curtisw, @dan thanks a lot for your effort guys! You are amazing.
I tried out the newest improvements and did some comparisons myself.
6.29.20239.15172 vs. 7.0.20266.16016 running on macOS 10.15.6
Here is my experience:
Canvas frame rate seems to have increased about 2x (This was measured by video recording the two versions and counting frames). And one can really feel the difference, when zooming and panning around!
The speed of resizing empty GH windows has increased significantly as well, being around 5x faster (from around 0.6fps to around 3.5fps)
Next I compared those improvements to the current Windows version. GH in Windows is about 3-3.7x faster.
Furthermore, resizing GH in Windows works in an instant. Actually faster than resizing the Explorer window, which is very funny.
You guys made some great progress here. Overall GH frame rate has gone from being about 6-7.4x slower to only being 3-3.7x slower, which is great!
However, as can be seen, some improvements still have to be made. Please let me know if I can be of any help!
Best wishes,
Rudi
Thanks so much for the detailed testing @rudolf.neumerkel! Yep, always room for improvement, but Iām glad things are a bit faster.
Sure thing @dan, it is a pleasure being able to help a bit.
Are there any further canvas fps improvements, that we can expect with RH7? I am now working again on some larger scripts and am getting frame rates as low as 6fps
in some areas (only using half of my 16" screen). Keep in mind, that this also slows down moving and adding components to the canvas.
Did you find out any new bottlenecks?
Thank you and have a great day!
Some small issue I just foundā¦
Downloaded the script from Daniel“s answer:
There is some text / graphics on the top of the canvas.
Framerate with text: 6fps
After deleting the text: 30fps