I have recently switched back to Mac again and had a little bit of time to try out the new Rhino for Mac. First of all congratulations and thank you for the amazing work that has been done so far! Rhino for Mac has improved A LOT (lots of new features and enhancements etc.).
First of all the trackpad integration is awesome. Panning and rotating around feels extremely smooth and even in Grasshopper it works great! And there are a ton of new features that weren’t available before (I am a huge fan of the cross platform development)…
Here are some wishes for improvement:
The Grasshopper canvas could be smoother. When I check the redraw speed, it tells me something ridiculous like 800fps, but it actually often feels more like 15-20 or so.
The zooming behavior in gh with the trackpad is great, but with a mouse it is nearly unusable (Logitech MX Master) since it zooms way too aggressively or seems to behave non-linearly compared to zooming in the Rhino-viewport. Would be great, if it worked the same way, it does in Windows.
I am using the gh-shortcuts for change trees constantly (F for flatten, G for graft etc.). In Windows I just select the component and press G, but in the Mac version I have to press G+Enter, which makes my workflow may slower…
Some improvement for Cycles would be much appreciated, but I posted that here already
The plugin support/availability situation could be better…
minor things:
panning and rotating in Rendered Preview with the trackpad is very smooth, but zooming is lagging a bit
while moving around in very large files, Rhino for Windows switches automatically to a wireframe mode if the framerate drops too much, this is not the case with the Mac version.
It is cool, that there is some Touch Bar support, however it would be cool, if it were possible to manually chose some favorite commands to add to the TouchBar.
All in all i am very happy because I can do a lot more in the Mac version, where I previously had to switch to BootCamp.
Let me know if you need any further details and much success with further development of Rhino and Grasshopper!!!
here are some more things that could be improved as far as UI experience goes:
The window resizing is very slow. Having rhino and gh side by side and resizing them is very cumbersome.
While working in gh and having the gh-window activated, it is possible to pan, orbit and zoom around in RH without clicking into Rh, but it is not possible to use the „pinch to zoom“-gesture - only after clicking in to the Rhino window.
Thank you for your suggestion, but that does not help since it only changes the Rhino Viewport Scroll behavior - but I am after the gh-scroll behavior…
To make my point clear, here a more exact description of the problem:
When I scroll the mouse wheel e.g. 1 full rotation slowly it zooms out a certain distance, but when I make the exact full rotation in a fast manner, it zooms out way too far…
Hey @rudolf.neumerkel I saw your list and I’m working to catch up after an extended absence. Sorry I don’t have a constructive reply just yet, but just to let you know that it’s not off my radar.
To recap, I think the most important thing is the responsiveness of Grasshopper. Having the UI react with higher fps and shortcuts like G for Graft or F for Flatten are a huge deal. When you are working on a new script/project the faster and smoother you can get something done, the less distraction you have and the better you can focus, enjoy and lose yourself in the work…
I wish I had a better answer for this one. We’ve worked hard to make Grasshopper on Mac more responsive, but we feel like we’ve exhausted our optimization options. This topic goes into it a bit. We have been considering some fundamental changes to get better results, but they might require some significant rewrites and we’ve been carefully considering where this effort should go.
Got it. Logged here:
RH-57216 Grasshopper: Parameter input keyboard shortcuts require enter or space to complete
Could you elaborate on the different technologies used in Windows/Mac for the canvas UI and on the fundamental changes needed? I would be also happy with just some links related to those topics.
As far as I can remember, there was a similar issue in RH for Windows (?). I used to keep my GH windows as small as possible in order to get higher fps of the canvas. There was a point, where full screen GH was quite unusable… That may have been also related to me using a 4K Laptop.
There is a similar behavior right now on GH for Mac:
The smaller the window, the faster the canvas (kind of obvious) and maybe the best strategy for now…
This is my current “canvas redraw speed” btw - pretty EPIC in theory:
That said, I played around some more and found some interesting things:
The frame drop even occurs when I have a fresh gh-file with 0 components and running it in full screen.
Being depend on the canvas UI, resizing a window is really slow…
Zoom factor also seems to play an important role
Rhino and GH have already become very good in lots of places… Panning and rotating around with the TouchPad in the 3D View works like MAGIC, the usability the GH canvas with the TouchPad is also great and of course tons of features have been added. I
it would be cool if the GH canvas smoothness could catch up as well.
What is the current case with GH2, is it built up using a different UI technology? Maybe it makes sense to implement those new strategies there…
Thanks a lot for the development until now and have a great evening!
Greetings,
Rudi
p.s.:
would be nice, if the scroll-wheel issue mentioned above could be fixed in the meantime.
The performance hit is due to the translation from System.Drawing to Core Graphics (macOS’s graphics API). It comes down to the following:
Translating from System.Drawing API’s to Core Graphics has overhead, and with so many elements on the screen it adds up.
System.Drawing has features that are slow to do in the same way in Core Graphics. We have our own custom System.Drawing implementation that maps to CoreGraphics which is very slow since we emulate the System.Drawing API
On Windows there is very little .NET implementation as most of the calls go directly to native GDI.
Mono is slower than .NET Framework
Core Graphics is slower than GDI
As far as solutions go, we are keeping our eye on SkiaSharp. Skia is what Chrome uses to do drawing; the primary author is Google. SkiaSharp is a .NET wrapper around Skia. We are a bit concerned that it doesn’t yet have a Metal back-end. Metal is the modern graphics API Apple is pushing us toward, now that Apple has deprecated OpenGL.
GH2 is using Eto.Drawing, rather than a partially implemented System.Drawing. Eto does not have such a hefty emulation layer and the functionality it provides mostly directly translates to Core Graphics, hence is also why it has a more simplified API. If this proves to be performant, we might not need to switch to Skia.
I believe this is already on our list.
RH-36624 Grasshopper: Preference to inherit/lock scroll-wheel zoom to Rhino’s settings
Thank you for the detailed response!!! I will take my time to go through it more thoroughly!
I don’t think these are the same issues. In the video attached you can see, that the wheel is being scrolled two times with approximately the same distance, but with different speeds. Normally this should not make a difference in GH (in Rhino it doesn’t). However as can be seen, when the mouse wheel is scrolled in a fast manner, it zooms in and out like crazy… this is a bit annoying, since I like to move fast on the canvas… as a comparison, in GH on Windows this is not case.
Skia and Eto.Drawing sound like good news!
Utilizing the GPU with Metal for the GUI sounds like it would result in crazy performance gains…
Hope the McNeel team can find a good solution as far as optimal hardware utilization and cross platform compatibility goes. (I guess Skia would then be used on Mac only, while continuing with native GDI on Windows?)
Wishing the team much success!!!
p.s.:
I realized that GH for Mac is actually drawing more (?) curves at the GUI for components than the windows version. As can be seen in the screenshot (you have to zoom in a bit), all of the components on the Mac canvas have additional white fading curves. Maybe removing those (and matching it to the windows canvas) could safe some unnecessary computation power? Those outline curves could add up a lot in a dense canvas…
Hey @dan, did you have some time to look a bit into the scrolling issue described above and shown in the video? Hope my description was understandable…
Yes, I’ll look into it. I apologize for the delay. What has slowed me down is all these different requests in the same topic. It’s literally work to disentangle them all and it forces us to re-read the entire topic each time to make sure we haven’t missed anything. In the future, having them separated out into separate topics would be helpful.
RhinoWIP 7.0.20119.12106 (Mac) vs RhinoWIP 7.0.20119.13305 (Windows)
I have an old Logitech G5 mouse with a scroll wheel, which I’m using to do the tests on both Windows and Mac. When I first ran the tests, I did it with Windows 10 in a Parallels VM and they behaved identically, so I broke out my native Windows laptop and now I see what you are saying.
That leads me to believe it might be that this is a case of macOS’s accelerated scroll “feature.” I found this question on StackExchange:
I installed “Smooze” and unchecked “Animate Scroll” and Grasshopper on Mac now behaves as Windows does (no acceleration). Ok, I’m not proposing that we install a separate app. However, I will dig up some Logitech software to see if it provides similar control over the mouse or not.
I was unable to find any recent Logitech macOS software that supported my old mouse. Perhaps you will have more luck. If you do, look for preferences related to scroll acceleration. If they are there, disable them. I’m curious to see if this provides the behavior you are looking for (or not). Smooze appears to.
Obviously, we can continue the debate as to what Grasshopper’s behavior ought to be, but I’d love to hear from others on this. Perhaps we can provide a preference in Grasshopper on macOS to pay attention to scroll acceleration.
I haven’t looked into this yet, but we may be able to do here is disable scroll acceleration with non-magic mice or trackpads. Do you get acceleration when you scroll in Safari or other macOS apps?
Just to chime in on this specifically, it’s actually a bug on macOS in that it is supposed to clip to the outside of the components so you don’t see that outside part. The highlight on the inner side is part of the same operation with 3px width. Clipping it properly would probably make it slower…
If it makes sense, you could split the scrolling issue into a separate topic (I don’t know how to do that)…
I am using the Logitech MX Master and couldn’t find any helpful settings in the LogiOptions.
However unchecking “Animate Scroll” in Smooze and reducing the vertical lines number from 2 to sth around 1 helps!
Accelerated scrolling makes a lot of sense for webpages and documents for example, but not so much in the GH canvas. When I am scrolling in&out in a fast manner in GH, I do that because I want move around the canvas 2x as fast, not because I want to zoom out more.
Yes - while browsing or reading documents, but there it is not as noticeable or bothering. In the Rhino canvas for example, scroll acceleration is not happening. Would be cool if there was an option to disable it in Grasshopper!
