Slow canvas UI (with multiple elements)

When I have a GH file with many elements (see example screenshot), the UI slows down a lot. Panning, moving elements or creating connections. This does not happen with a small number of elements, or in the Windows counterpart.
Any thing I can do about it, or should we just wait for a more optimized version?

1 Like

Have you tried using Clusters?

// Rolf

Does the UI slow down with respect to things like panning and zooming on the canvas or does it slow down when you do something like change a slider value?

Panning and Zooming on the canvas. I am only talking about GH canvas draw performance. I could even be making only math with panels and expression editors. It has nothing to do with Rhino 3D viewport rendering.
Regarding clusters: It is “effective”, in the way that it potentially reduces the number of components visible at a time. Which is the main culprit, from what I’ve found: it is directly related to the number of elements visible on screen.
(I love clusters and advocate them, but sometimes it is useful to have everything on screen)

Ok; I just wanted to make sure. It sounds like you are already very aware of the difference in panning performance and solution performance.

1 Like

Thanks! Logged as MR-2953…so we don’t forget to address this. We’re still not at the point where we can focus on optimizing this. Nothing worse that premature optimization. Thanks for reporting it. If you can provide good demonstration definitions, that would also be helpful…otherwise, we’ll gin them up ourselves.

I opened the file with the intention of uploading it here, and I discovered that it was quite snappy. There was no software update in the meantime, as far as I know, so it might has something to do with “wear over time”? Maybe the computer was low on resources (I don’t think so). Anyway, here is the file:
fab_ruled_edges2.gh (121.9 KB)

Odd. Well, good, I guess. I suspect we still have some optimizing to do. So it’s great to have definitions that have exhibited problems, just for comparison purposes. Thanks for attaching it!

-Dan

Hello. Just wanted to bump. Using 5E92w now, and canvas interaction speed issues still around. Number of elements is surely a factor, as a new gh file is very snappy. I’ve noticed that in the file with many elements, it seems a bit quicker if I work in an empty canvas area.
Mac GH looks quite stable now, although there are still many polishings to do. I believe speed optimization is something that cannot be ignored at this stage.

I agree.

Philip

Panning and zooming with large definitions should be faster in the latest Service Release Candidate for Rhino 6 for Mac.

Hello. I am sorry, but this issue seems still far from resolved.
I have recorded two Screen Recordings with Quicktime on my MacOS Mojave.
All Grasshopper files are the same, with the same underlying Rhino file.
One video features Mac Rhino 6.18, the other Mac Rhino 7.0 .
Both are compared to a Windows Rhino 5.11 running inside Parallels.
Even with virtualization the Windows version of Grasshopper is far superior in terms of graphical user responsiveness.

https://global.discourse-cdn.com/mcneel/uploads/default/original/3X/a/e/ae4bcb49d25aecdda48c31aa50f8c6626b5a9486.mov https://global.discourse-cdn.com/mcneel/uploads/default/original/3X/e/d/edbe2a3c7e7a01c509b6bb15a172413d9f6ec8b7.mov

HI @Pedro_Varela-

Apologies for the delayed reply and thanks for demonstrating this with videos. It helps to see the side-by-side comparisons.

Unfortunately, I think I need to do some expectation management here. We believe we’re running out of optimizations for drawing Grasshopper on Mac. We’re drawing Grasshopper using a different technology on Mac than on Windows and there’s quite a bit more overhead.

I wish I had a more positive answer.

Hi guys, I´ve just tried the grasshopper and the UI seems significantly slower than in R6 on windows (zooming, manipulating data etc). Do you also experience this issue?

Petr

Pardon my eloquence, but these are somewhat tragic news. After three years I created this thread, you confess/acknowledge that the Mac counterpart of Win Rhino is doomed at birth because of “a different technology”. I don’t know the internal workings of the software, and what was the strategy for achieving a working Mac software based in a Windows software. However, there is a multitude of examples of how the platform is no reason for different magnitudes of performance in the user interaction with the software. I must give blender.org as a fine example. (I just wish the Windows and Mac versions of Rhino would be as similar as those of blender)

1 Like

I can understand your sentiment here in this regard.

Doomed? Are you unable to get your work done? Forgive me, I thought we were discussing a performance problem, not a bug that is preventing work from being done.

Which examples are you referring to? Are we still talking about Grasshopper on Mac here or…?

I started by apologizing my eloquence, and choice of words… so I ask you to take that as a filter. If I start working with a definition and it becomes large enough to star showing slugginesh (few dozens of components) I change to windows because i can get my work done faster. Faster as in two times faster. And that is a difference worth my previous post.

Hey, guys, I think I have the same issue on windows.
Here is what I stuck in. I am running a facade project, creating a gh file for generating root top model. For now this file contain 3197 object as doc info tells, and every time I make connection changes, it took almost one second to respond. I think it causes by branch modification, cause after every connection change GH need to generate branch structure accordingly.
Any suggestion to keep it fast? I already cluster many object, and that’s why there are 3197 objects but not 5000 objects… : (

Hi -

The issue is actually quite different on the Mac platform.

The general advise is to break down your huge definition into separate functional groups and save these separate groups as separate GH files. Then connect those separate files with the Data Input and Data Output components.

-wim

It is a good option to reduce the complexity of my huge definition.
I am just curious about whether it would speed up to pack huge chunk of batteries into single cluster or not. Considering that it can be disable all the batteries or only cluster itself, this method could be work in different ways.