@curtisw, did you have the time to look into the other factors as well? Would be awesome, if we could squeeze out some more fps here and there.
@diff-arch, my current (not so elegant) hack is to use an external 1440p display and have GH only as large as really necessary - sucks a bit, but speed is more important.
@curtisw, speaking of telepathy, here is a another script (of a friend of mine, I did not cause the spaghetti mess!), which performs very poorly. What do I mean by very poorly? Yes, only 29fps in a blank area of the canvas⦠not to mention the 10-14fps in dense areas. The script uses Telepathy, but I deleted the plugin to exclude the Telepathy issue. Please have a look:
Also, here is a super small script consisting of exactly 16 objects. Filling half my MBP16" screen it barely scratches 30fps at 100% zoomed in. This is really a freaking small script.
This situation is not acceptable. I want to emphasise: These fps are not some visual fancy feature. They are a direct bottleneck to the speed of the UI and thus the user input. This stuff is slowing down my - and probably many others - work on a daily basis. We have to find a solution here. Please let me know if I can be of any help.
@curtisw, @dan hope you are doing great!
Just found some good examples that show a bad canvas performance: The example files from the Karamba3D website. For example, this one:
With 50% of my screen filled, I barely get 13fps⦠Deleting the scribbles bumps it up to only about 18fps.
Can you do some analysis for potential bottlenecks on these files? Canvas fps is still super critical!!! and I think there are some low hanging optimization fruits here.
Is anyone getting Rhino7 GH Mac canvas UI speeds that are decently usable?
If so what hardware are you using?
I have been trying to us GH Mac on my older Mac Pro after my Bootcamp Windows partition died, but the slowdown in the Grasshopper canvas is quite shocking, and unusable, and on identical hardware that was working well on the Windows side.
Iām trying to figure out my options regarding rebuilding my Bootcamp system vs. buying an M2 Macā¦
Hey @LeoPedersen, I found some workarounds that speed it up:
I am using a 1440p external display (in closed clamshell mode), the lower DPI increases cavnas fps significantly
reducing the Grasshopper window size to what is really necessary
I am still on an Intel MBP, but did some quick testing on the M1 Macs, interestingly the canvas fps was sth like 2x faster⦠havenāt tested the M2 yet though (will go to a nearby Apple store to test Rhino 7/8 when I find some timeā¦)
That being said, there are is still a large need for improvements⦠I also posted some bottlenecks above that have not been addressed yet. Improving canvas fps, is more than just something pleasing for the eyes, it is the limiting factor of how fast one can interact with the whole Grasshopper UI, thus how fast one can work!
@curtisw, @dan I think the gh-files attached above show some clear bottlenecks. Maybe there are some low hanging fruits regarding UI performance there. Pleeeeeaase have a look at them. UI smoothness is crucial for professional and intense work.
I have an M1 MacBook Pro and - with 01_ParametricTruss.ghās canvas fullscreened - Iām getting between 20-23 fps on an external display (27-inch 5120x2880) without Karamba 3D installed (afaik, Karamba is Windows only). Iām testing in the latest RhinoWIP. If I reduce the resolution to somewhere close to 1440, Iām getting 38-40 fps.
Iām wondering what I need to do see this significant bottlenecks. I can test on an older Intel Mac tomorrow.
Karamba is available for macOS, but only in RH7 for some reason via the package manager.
I ran the same test on RH8 without Karamba (so with placeholder) elements and got 9,8fps, after first clicking on view entire document on my Intel MBP16". Would be interesting what you get with the Intel Mac.
Running the same test with RH7 with Karamba installed, I get 6,6fps in full screen with view entire document.
Just opening the file and filling half the screen (and zoomed in, as attached below) I get 11,26fps. Unacceptably slow, as all UI interactions are limited to this frame rate.
One more interesting point: Creating an empty GH document and viewing it in full screen, I only get 31fps, which sounds very low to me for an empty document. Maybe there are some bottlenecks regarding the grid lines?
Do you think that Metal integration in Rhino 8 will bring some improvements in terms of performance for these persisting canvas redraw issues in Grasshopper?
I repeated Rudiās process in Rhino 8 WIP and get 29.98 fps at 2560 Ć 1440 pixels screen resolution with the M1 Ultra.
Ah, I see. I seriously doubt it matters. I imagine the missing placeholder components are faster to draw than actual components (any components), but probably not impacting the overall performance.
I agree this is quite slow, but I donāt know if thereās anything we can do to squeeze more performance out of this going forward. The fact that its significantly faster on newer hardware is telling.
I will see if I can get the same slow framerates on an empty document with older Intel Mac soon (I canāt promise Iāll get to that for another couple of days though). I want to see if I can reproduce what you are seeing as thatās going to be a precondition of doing any kind of performance tuning (if we can do any).
Hello again. I am now using a MacBook Air M2, so I am off to new tests. I am pitting a native MacOS Rhino 7.29 against a Win11 Rhino 7 SR28 running inside an UTM virtual machine, running in the afore mentioned MacBook. The results show a large degradation in fps when using a zoomed view inside the GH canvas. The graph is self explanatory.
MacBook Air M2
Windows 11 ARM running inside virtualized UTM / Rhino 7 SR28
zoomed 3components: 44fps
zoomed 10components: 41fps
zoom 166components: 56fps
p.s.: it is rather sad that I have a much more pleasant experience running Rhino inside Windows inside MacOS, which is even unsupported by Apple; ruining my MacOS experience; consuming valuable system resources.
Thank you @Pedro_Varela for your infos! I agree, the Mac GH canvas still has to be improved significantly.
I already provided a lot of example and bottlenecks that could be improved upon.
I.
I recently discovered another bottleneck. When using Karamba components, it seems that a lot of them are being rendering even though they are not being displayed. This issue persists on Windows as well as macOS.
In the following file, I duplicated a small script 4 times, just to make problem more easily visible. The zoom into an EMPTY area of the canvas. With half the MBP16" (Intel) screen filled I get 15fps instead of the expected 60fps. This is clearly an issue, that should be fixable.
This bug prohibits users from creating larger Karamba scripts, as they become incredibly slow!
Please take a look at this @curtisw, @dan. (Karamba Trial version can be installed via the package anager in RH7)
GH2 uses the WPF framework for UI drawing instead of GDI+. WPF is faster at some things (drawing bitmaps) and slower at others. So optimisations will need to be quite different from before. But yes the display performance is an issue Iām aware of. The general solution is to draw fewer things, but thatāll only take me so far before it starts to look very wrong during panning/zooming/dragging etc.
Iāve recently managed to massively speed up trimmed string drawing (particularly on Mac) by caching some results, so Iām hopeful that further improvements that donāt require lowering the detail are still very much possible.