I tried to test V6 now for a few hours.
Great: the screen modes. Rendered Mode, Arctic Mode, Pen Mode. Great for Architecture and Design.
The rest… I don’t know. Texturizing is complicated, rendering doesn’t seem easier (since Rendered Prewiew or ray tracing screen mode is great … a bit disappointing, performance is a disaster.
I was always a huge Rhino fan, but this one is really mediocre at best :-(((
I appreciate it that you are letting us know. I’ll keep looking into this issue as I believe the display in general “should” be faster than V5 based on the redesign we did. Either the OpenGL drivers are severely lacking or there is something subtle that we need to find and fix.
FWIW: on quadro M4000
V5 win:
Display mode set to “Wireframe” = 0.44 seconds.
Display mode set to “Rendered”. = 1.11 seconds.
Display mode set to “Ghosted”. = 0.41 seconds.
Display mode set to “X-Ray”.= 0.33 seconds.
Display mode set to “Pen”.= 0.53 seconds.
Display mode set to “Technical” = 0.83 seconds
v6 win:
Display mode set to “Wireframe”.= 0.41 seconds. (246.31 FPS)
Display mode set to “Rendered”.= 0.56 seconds. (177.94 FPS)
Display mode set to “Ghosted”. = 0.52 seconds. (193.80 FPS)
Display mode set to “X-Ray”. = 0.41 seconds. (246.31 FPS)
Display mode set to “Pen”. = 1.08 seconds. (92.76 FPS)
Display mode set to “Technical”. = 1.84 seconds. (54.26 FPS)
Not that much difference, except for tech.
BUT: tech display in v6 is much better/precise
A lot of the difference between V5 and V6 (Windows) will be what types of objects you have in your scene. For example, V6 is way faster with large point clouds and meshes.
It looks, from a user’s perspective that beyond tuning up the display, what is needed is to reconsider shifting priorities in the development and move the integration of Metal from V8 to V7
thanks a lot
Akash
Just trying to help add a data point to this thread… In my sessions with Rhino 6 WIP, I’ve not noticed any attention-grabbing lag compared to the pre-WIP days of using Rhino 5 Mac. I downloaded the TestCubes file and in just some routine orbiting and zooming, everything pretty much seemed on-par. As Marlin instructs not to use the test function, I’m only relaying my sense of the WIP based on very light navigation in various display modes (wireframe, shaded, rendered, arctic, etc)
Made a demonstration screen recording, but at 107megs, the forum’s putting a hard rooster-block on uploading it. 
Using one of the first retina MacBooks, it’s been running with an Nvidia GT650M GPU. Quite honestly, recently hearing the bitter contention between Apple and Nvidia, I’m not sure if Mojave is even using it -or- if I’ve been running strictly on the integrated Intel 4000 graphics all this time.
I’ve been holding out for a new MBP (AMD architecture) and am likely to upgrade to RMv6 when it lands, but this thread seems to suggest I’m in for some less-than-good times ahead.
If there’s anything the Devs would like us varied users out here to test/perform, let us know to further help pin down this issue.
Thanks for clearing that about Testmaxspeed, but what are your thoughts on the main topic here; the allegedly rather bad performance of RhinoWIP 6 - compared to its predecessor -, and the impending release of what seems to be a still unfinished product?
Let’s be honest, that’s the perception that many Mac users, who participated in the beta, probably have!?
Furthermore, I don’t think that it is productive to tell people, who are genuinely worried about the state of Rhino for Mac, to stop doing one thing, because it’s erroneous, but leave them standing in the rain when it comes to tackling some of the “real” questions!
How about some words on the objective performance, on how to really evaluate it on an individual level, which Mac hardware to prefer when looking for Rhino performance, etc.?
Yes, yes, yes! 
Thanks, for looking into it!
What I don’t get though is, why you guys always say it “should be faster than V5”, when in fact it is not for a lot of users. I don’t mean to be rude, but are you even testing this stuff on anything other than a maxed out (i)Mac Pros?
So you have been developing Rhino 6 for Mac for sometime now and up to now you hadn’t noticed that the OpenGL drivers “are severely lacking” or “something subtle” has still to be fixed? 
Don’t be ridiculous! You can even check which GPU is currently being used by which application.
Either way, my theory is that Rhino plays well with Nvidia chips. Someone even mentioned that they are less of a pain to develop for, compared to GPUs from AMD, which all modern Macs use.
There’s even a new discussion floating around that describes how well the current Nvidia GPUs work with live raytracing, which doesn’t seem to be implemented on AMD chips yet, and how great this will be in Cycles…
Yes, please let us know!
LOL, imperial! 
Here are two of our computers.
The mac mini is not so crisp and nice in rendered view like the macbook pro, which I can understand since it has no proper GPU chip.
Meanwhile on the performance side both of the computers are performing very, very slow in Rhino v6 mac. Going to full screen mode, changing view, opening saved views panel, scrolling. All feels laggy and painful and has a substantial delay.
I confirm that both of the computers run Rhino mac v5 like heaven. We had NO performance issues (we are doing small architecture projects and furniture) at all with this machines running Rhinoceros mac v5, Blender 2.8, Affinity Photo Designer Publisher, Maxwell Studio.
Just Rhino v6 mac wip and beta was always a nightmare.
This probably explains why with this test, the sample file is “faster” with Rhino 5 but … actually I clearly see that (at least on my iMac) it is faster with Rhino BETA.
-Simon
It is now definitive! jeff you won! LOL 
-Simon
heh, working with this client in particular gets real wonky as far as units…
their design team is in Italy… most of those drawings/pdfs come in rounded to the nearest 5mm… their fabricator is in Taiwan and they use proper/true dimensions which work with various materials.
we do most of the U.S fabrication… I use Rhino for all the modeling and my preferred units are decimal inches… when I make cultists for our shop, those are always dimensioned in fractional inches… if I send drawings back to Italy, I use dimensions rounded to the nearest mm… if I talk to the company’s U.S office, I use feet&inches (to nearest 1/2inch)… except the French guy there… then it’s cm… when I send Rhino files to the CNC, I have the post processor convert to mm…
but the people in Taiwan, the people who actually matter as far as being on the same page and having the components fit together… they use Rhino too… so we just communicate via .3dm and everything works out well. (when/if their components are needed for the US installs)
but generally speaking, even when metric isn’t involved… all communications I do are in fractional inches (or feet&inches if large scale)… but I model in decimal inches. (mostly… but if I’m doing more of a traditional build with typical woodworking tools, I’ll use fractional inches since all the scales are laid out that way… if the robot is involved which is most projects lately… then it’s decimal)
but seriously… not as confusing as it sounds.
Is there anyone else where the layouts are gone when you open a v5 file in beta v6?
I tried on several files. After a restart of Rhino mac v6 beta I cannot reproduce this problem… Now it opens all Layouts correctly.
What I noticed though:
When I am doing a grasshopper file from scratch in v6, after baking the geometry I sometimes am not able to close the grasshopper window. Everytime I click the red close button the Grasshopper window pops up again. The only way to solve this seems to restart Rhino.
You might see some performance improvements in the latest RhinoBETA. Mileage may vary. @stevebaer did some relatively safe optimizations and is investigating some others.
Thanks @dan, for letting us now. It’s hard to say if the performance has improved though, since there is no objective way to test, at least that I know of. Viewport navigation seems fine for the above example, although the Ghosted view (that I like to use) still seems far slower than in Rhino 5.
Is there a way to remedy the menu flickering, whilst manually manipulating curves by moving their control points? Each time I select, drag, and drop a control point the right- and left-side menus change to other states and back. This isn’t an issue, if you do one or two operations, but if you perform a lot of, consecutive modelling the flickering menus become quite irritating.
I am seeing performance issues with ghosted mode and am looking into this now.
From the fist little tests of the new beta v6 6.16.19190.13174 performance has definitely improved.
Navigating in the viewport seems now faster, also scrolling and changing view modes.
Still very slow: Named Views Panel
Still unbearably slow: Working in 2d in wireframe mode with hatches, dimensions and lines. Scrolling and panning very laggy and the mac waiting ball appearing all the time
But this seems a step in the right direction!
Good to hear we are heading in the right direction. Thanks for letting us know.
Hopefully, you have posted this file and instructions for reproducing this one (the topic is getting long so I might have missed it). This is certainly the sort of thing we need to investigate more. I hope it goes without saying that we are certainly not seeing this behavior.
Great news! There was a subtle bug introduced a little over a month ago that had a huge impact on ghosted mode. We are testing now and will hopefully have a new build soon to play with that makes ghosted mode feel a bit more like butter than molasses.
Thanks for helping to track this issue down./
