I think and I can confirm that R6 performance is a bit painful issue, even though many had been improved, there is still unused potential. But I dont know how realistic it is since Rhino seems to be tuned mainly for nvidia cards.
I think it’s more like the other way around, that is Nvidia card drivers are more tuned for CAD applications than AMD/Intel drivers are (they are more tuned for gaming apps). That seems to be the case for Windows applications anyway, I do not know how AMD/Intel drivers work on the Mac side. Add to that the fact that Apple is going “Metal”, so their OpenGL support may no longer be given all that much attention to.
Better Comp or Laptop = an extra 200-300$
Waiting on an update and your ocmputer to load = alot of stress and wasted time
Take the matter into your own hands and do what you can with what you got.
We don’t “tune” Rhino’s display for any specific GPU. We do have a handful of workarounds for known driver bugs and there are several that we have to work around on Mac which has been personally pretty frustrating.
One of the known bugs is with respect to AMD and Intel drivers going into what seems like an emulation mode when enabling tessellation shaders for wire drawing. This performance is so bad that we just disable tessellation shaders all together on these GPUs and switch to an alternative technique for wire drawing. We have submitted a sample for repeating this bug to AMD and am hoping to hear back on if there is something that can be done to improve this situation. These same computers running Windows (and Windows drivers) do not exhibit the issue at all and work just fine drawing tons of curves on the screen using the tessellation shaders. This is OpenGL which is cross platform code and there are very few differences between the Mac codebase and Windows hen it comes to display.
I hate to make this look like finger pointing, but at the moment I need to rely on feedback from the GPU companies to figure some things out.
1 Like
not at all, I’m glad that you make clear that something is not working well at the mac side. And at the same time this makes the choice for me even more easy to get rid of this macbook and look for a pc replacement. I really like the machine, the screen and the trackpad quality, but in Rhino v6 it’s a total disaster at the moment.
what if you just skip the pain in trying to jump hoops and focus on metal right now instead, does that sound unrealistic? if i count 1 and 1 together that would make a win win as far as i understand it. or maybe that would leave a few old laptops mine included behind… so maybe a bad suggestion. i dont know i just hope you find a solution.
It does sound unrealistic for Rhino 6 and Rhino 7. Switching to metal is a massive task and will come with its own new set of pain points
yes that is clear, you pointed out version 8 may be realistic before, its ok for me. but maybe till then i can only suggest not to make any experiments and just use what has worked in 5, what would that really lose?
It would also be a massive effort to switch the display back to what was in V5 with Rhino 6. V5 was based on legacy fixed function OpenGL 2.1 and we switched to OpenGL 4.1 core profile based on recommendations at the time.
yes that would not make sense i agree, then rather use that effort into the future, get the code tweaked a bit that we can work and then maybe just a bit sooner and even if its heavy -> metal for some 7.3000282837 service release whatever, who cares about the numbers anyway as long as it works then, at least IMHO.
+1 for transparency and clarity, thanks…(eases wtf factor)
I was running the 6 beta on a 2010 MAC and saw no problems.
This can be anything. But what it comes down to is that most if not all the MacBooks that have issues are the later builds with amd graphic cards.
What are the specs of this system and did you notice any difference in performance between rhino 5 and 6?
OK lock n lol baby, you guys have tweaked something with the latest update and its BLAZLINGY FAST. come and get a hug for it!!!
This is great news… However, there are several changes that have gone in over the last couple weeks, so it’s hard to say/know which one(s) actually have opened this up for you.
There was a huge resource drain in the way MacRhino was allocating and using OpenGL drawing contexts, which also revealed problems when trying to use external devices via AppleTV, AirPlay, and SideCar. We have eliminated all of that, and now only one context is being used for all drawing… That’s the most significant change I can think of that might be the reason you’re seeing better results…but I’m glad things are better (for now 
)
Thanks,
-Jeff
1 Like
thanks for the feedback Jeff.
i really hope you are not trying to tell me something subcontextual here 
can you wrap up in a short sentence why you tried to engage with these?
Because users were reporting bugs complaining that Rhino didn’t work with them… All you got was blank viewports… but not anymore, it’s been fixed.
-J
i meant why is Rhino running in AppleTv etc. doing a bit research i found out what sidecar is 
sorry, i am not fully up to date with catalina, still running Mojave.
AppleTV is really just another iOS device… Using “AirPlay”, you can connect your MacOS computer(s) to whatever the AppleTV is connected to… Think of it as a wireless HDMI cable… So you can now use your UHDTV 4K screen as an external monitor. SideCar is similar, only it works directly with iOS devices (i.e. Tablets and such).
-J
cool, so all you got to do to make Rhino a bliss for Ipad is to make some UI adjustment for sketch
1 Like