Slow canvas UI (with multiple elements)

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 :pray:

Best wishes from Vienna!
Rudi

Studio_HB_Skript.gh (1.1 MB)

1 Like

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. :yum:

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. :scream:
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! :mask:

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. :wink:

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.

2 Likes

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)

1 Like

RH-59737 is fixed in the latest Service Release Candidate

2 Likes

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.

3 Likes

RH-60220 is fixed in the latest Service Release Candidate

2 Likes

@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:

  1. 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!

  2. The speed of resizing empty GH windows has increased significantly as well, being around 5x faster (from around 0.6fps to around 3.5fps)

  3. 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

4 Likes

Thanks so much for the detailed testing @rudolf.neumerkel! Yep, always room for improvement, but I’m glad things are a bit faster.

2 Likes

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

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!!! :rocket::heart::coffee::earth_africa::ocean:

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 Geometry component somewhere with some distance away from all the other components
  • checked the Canvas RedrawSpeed in 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!

@curtisw, @dan

@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.

@curtisw, can you reproduce the same issue on your machine?

Cheers, Rudi

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.