Hey @rudolf.neumerkel,
Thanks for following up! I’m seeing major slowdowns with that definition too. I’ve created a new YT for that RH-62333.
Cheers!
awesome, thank you for the quick reply!
I am sorry for the not so scientific nature of my reply, but… Rhino 7 is handling Grasshopper canvas much better. Sometimes I need to use Rhino 5 as well and the difference is gigantic. Not on par yet with the Windows version, though.
Keep up the good job on the improvements! I still have faith that one day both Win and Mac will be the same in terms of performance.
1 Like
Totally agree sir. Canvas performance has improved a lot. General speed and as well as UI fixes, zooming smoothness etc. are much better now.
But as Dan mentioned there is still some room for improvement - I am still experiencing heavy frame drops in most of my (larger/denser) scripts.
Cant wait to see some more fps gains, guys!!! 
btw, I already wrote about this but: it is crazy how well the Trackpad functionality is implemented!!! It is amazing. Feels about as fast as with the mouse!
edit:
Basically, scripts larger than around 1000 components get so slow that proper work is not possible or takes more twice the time as it should, which is obviously not good, when time is limited. Interestingly performance in that case has barely anything to do with actual displayed components - even a few currently visible component would only display with 10 fps or less. Not so much fun debugging a large script in that scenario…
Just to elaborate on this sentence:
- I opened a larger script (>1000 components)
- Created a single
Geometrycomponent somewhere with some distance away from all the other components - checked the
Canvas RedrawSpeedin fullscreen
The result: 8.47 frames/second for a “single” visible component. (compared to over 30fps if I paste the same component in an empty script).
Hopefully this hints to an underlying issue - not only actively shown components, but amount of components in the background as well… Hope this helps!
@rudolf.neumerkel thanks for the follow up and details.
When using the script you posted before (Studio_HB_Skript.gh), I am seeing ~30 fps when doing the same steps. It could be a “rogue” component that is causing the issue, by doing excessive drawing or processing even when not on screen. Are you able to replicate the issue with that script as well?
Also, would you be able to send the script you’re using that causes the larger slowdown? It would help to track down the issue.
@curtisw thanks a lot for your answer as well as the quick investigation!
I can confirm: the Studio_HB_Skript does not seems to have this kind of slowdown. Here is the script which causes the issue:
210220_Iteration.gh (775.8 KB)
This is the case independent of how large the window is btw. I am getting 9fps also with a tiny GH window.
p.s.:
As a side note, speaking of larger scripts.:The Search function of GH also seems to behave differently with larger scripts. The component you click on in the dialog will be to be displayed in the center of the window and grayed out area seems to have some graphical issues - see the screenshot attached below: On the left is a new script with 2 components, on the right is a larger scripts (this seems to be happening with many of my scripts). Maybe this issue is related, IDK.
Wow, this file has quite a few third-party components. I’ve hunted down and installed most of them (not all), but I cannot reproduce this. I get faster redraw speeds if I zoom into a single component than if I zoom out to the entire graph.
Deinstallad ALL plugins I could find from:
- libaries folder
- user objects
- package manager
Opened the script without installing all the plugins. Frame rate of an empty area increased from 8.5 to 12. But still way to slow - in an empty area it should be maxing out at 60fps as it does when I open an empty document.
Anyway, I have not encountered this problem in another script yet, so for now it is not too urgent. I am more interested in overall canvas performance improvements and this is a very strange but specific issue… (still experiencing an average frame rate of 12-14fps, when I am checking in from time to time in my usual scripts)
Fun fact, I remember @DavidRutten allegedly stating a while back that Grasshopper is not intended for having more than 150 (?) components on the canvas. And that bigger definitions should be clustered and/or spanned over multiple files. 
true that. Realized this way too late tbh…
However, most of the UI performance issues, have more sth to do with currently visible number of components on the canvas, rather than total amount. Canvas performance can already be slow with a script with 30 components
Hey @rudolf.neumerkel,
Thanks again for the sample file, and sorry I missed responding to your earlier messages.
I tried out the file in the profiler and when in a blank part of the canvas I found that the Group, Relay, and Placeholder components (when you don’t have the specified plugin(s)) still render even if out of view. There may be components in the missing plugins that need to do the same bounds check too (if they override the Render method), but unfortunately only the plugin author(s) can fix those up.
I’ve created RH-64310 to fix that up. After those fixes it gets it back up to near ~60fps at an empty area of the canvas (which is the max on macOS due to its limiting to the screen refresh rate).
Cheers,
Curtis.
1 Like
thanks for your answer! There are some things which I did not understand:
to make things clear, what do you mean by
- groups? → the colored grouping boundaries?
- relays?
how did you find that out btw?
what is the render method?
Correct.
These little doohickeys:
I run Rhino using the Xamarin Profiler, load up the file, navigate to an empty area and run the View > Canvas redraw speed a few times. It spits out this type of info, which shows what is using the most CPU
This is the GH_Attributes.Render method for custom components. If the components are simply standard without custom drawing, it isn’t usually a problem.
Hope this helps!
got it, thanks for the explanation!
So you where able to fix the issue? Or is it something that depends on the plugin authors?
to share another super slow definition:
The example file of the official GH C# primer. Getting only 8 fps with a canvas size half of my MBP16" screen.
C#ScriptingForGrasshopperSamples_1stEdition_20200318.gh (517.2 KB)
small hint:
- all components disabled (by default) = 8fps
- all components enabled = 12fps
maybe the hatch pattern of the disabled panels causes some slowdown, idk
it seems to me, that the same issues with the bounds check apply here as well
Copying only 16 components (+ 3 group rectangles) into a new empty script improves frame rate to 20 fps, which is much better, but still not acceptable for such a small amount graphical elements… Hope we can find some other bottlenecks here
I’m testing @curtisw’s fixes for RH-64310 right now. I’m seeing speed increases in the the 210220_Iteration.gh file posted above, but no change in this file 
here. That does make sense as Curtis’ fixes were for groups and relays.
Thanks for testing, sounds great! Interesting, that it does not affect the other file… on the other side, that’s good, as it brings some more potential improvements, if we can figure out the bottleneck of the second file.
btw just realized, that RH-64310, also fixes a mentioned issue from February 
Definitely. These sample files help, especially A/B comparisons.
1 Like