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