I still observe in version 11.0.0. (and since v 10.4.0) the important speed regression when rotating big 3D objects.

The motion is definitely much more fluid in version 10.3.1.

I am also on OSX (10.9.5), with a mid-2009 macbookpro which comes with two (nvidia) graphics card. Whatever card I switch to, the rotation is faster in 10.3.1

As previously observed by Szabolcs Horvat, I also notice that antialiasing is disabled in v 11.0.0 while rotating (?)

(My 3D graphics test object is Sander Huisman's first Lego shape in this post http://community.wolfram.com/groups/-/m/t/813449)

Really hope this get fixed very soon.

I am seeing the same lack of glitches on the 2016 MacBook after moving the slider all the way to the left (No Antialiasing).

I need to periodically make presentations, so I just bought and tested the Apple USB-C to VGA adapter. Regardless of having the Mathematica window located on the external display or the built-in display, the built-in display shows the glitches when rotating the head (slider back to Highest Quality)--though the glitches are not as persistent or noticeable.

An additional observation (should have posted on the other thread): rotating the 3D head is painfully slow on the MacBook ... Mathematica is using a little over 2 GB RAM and maxing out at 70% CPU during rotation with only one notebook open with one line of code.

That's interesting. It would be interesting to get some comments from people with MacBooks and similar computers (without dedicated graphics).

On my machine (Mac with dedicated graphics), version 11.0 automatically (and visibly) disables antialiasing during rotation. When the rotation stops, the graphics are rendered with antialiasing again.

With version 10.4 and 10.3, antialiasing was always on, both during rotation and static display.

I got an e-mail from tech support that the matter had been turned over to the developers. Since the original problem was fixed for Macs with a dedicated graphics card (fixed in the first beta for M11), perhaps the problem will be fixed for the rest of the Macs for 11.0.1 or 11.1.

I thought that this issue had been resolved for v11. However, it is resolved only for Macs that have dedicated graphics cards. (During the beta tests, I just checked my 15 inch Retina MBP with a dedicated (NVIDIA) graphics card.)

However, there are other graphics issues that have shown up with V11 for Macs that do not have a dedicated graphics card. This includes all MacBooks, all MacBook Airs, all 13 Inch Macbook Pros (Retina and non-Retina), and some 15 inch Retina MacBook Pros. The dedicated graphics card is an option with the top-of-the-line computer. I have no clue about iMacs, although I believe that the 27 inch models all have dedicated graphics cards, and the 21.5 inch models probably do not.

Instead of having a speed regression, the screen is messed up and the whole computer freezes, requiring a hard restart. I was able to reproduce this with the RotateCubes.nb from the beginning of this thread.

Wolfram support knows about the problem, but they might like to know the extent of the problem. I am basing my list of affected computers on the feedback on the other thread.

I desperately hope that will be the case ...

BTW it's not only the rotation performance that's bad. It also uses a lot more memory than 10.3 used to. In some cases more than 5x more (!!!). Combine this with the fact that the Mac front end is only 32-bit, thus can only address 2 GB of memory, and you get a lot of crashes due to out of memory problems.

Recently I've been working with large MeshRegions and things that were possible to visualize in 10.3 simply cannot be done in 10.4. The front end keep crashing.

I'll make a small test case eventually to report, but I really don't have time now.

Any news on the problem? I'm wondering whether there is workaround now so I can start using 10.4?

OS version (afaik) does not matter, feel free to upgrade your OS...

No, it is just the mac versions of Mathematica 10.4 and 10.4.1 that show this behavior, independent of your OS version (Capitan, Yosemite...). Btw: Mathematica doesn't have 'patches'.

nope, but I'm pretty sure it's independent of your Mac OS version...

@Sander Huisman, Thanks very much for the feedbacks. We take it seriously and are working on 3D performance optimization now.

I no longer have this problem with Mathematica 10.4.1 - it now uses the hardware accelerated libGL.so from my system. No idea why this became necessary and, further, why it is no longer necessary.

The files/directories may be named slightly differently between Linux and OSX but I think the key library is libGL.so (plus all the symlinks). On my installation this is inside the Mesa subdirectory - maybe on yours it's just in the Library directory or somewhere else?

@Arnoud Buzing and @Yuzhu Lu

Here is another simple test-scene that you can easily replicate. Can you confirm that these work smoothly on your installations and at what (perceived) FPS:

scene = Flatten[Table[Cuboid[{x, y, z}], {x, 0, 25, 2}, {y, 0, 25, 2}, {z, 0, 25,2}], 2];
Graphics3D[scene]
scene[[1]] = {Opacity[0.5], scene[[1]]};
Graphics3D[scene]

First is ~4fps for me. Second is ~0.1 fps, includes rainbow beachball between updates...

See also the video here: https://www.youtube.com/watch?v=UUis10bGohQ

It's probably already known since Linux uses OpenGL as well, but I am also seeing a massive slow-down with Graphics3D on Mathematica 10.4 in Linux (Arch, fully updated).

My SystemInformation["Devices"] output said that it was using the Gallium software rendering driver for some reason, so I tried removing the Mesa libraries included with Mathematica (SystemFiles/Libraries/Linux-x86-64/Mesa) so that it would be forced to use the system libraries in /usr/lib. It now shows the proper Intel driver in SystemInformation["Devices"] and the performance of Graphics3D is massively improved. I no longer have 10.3 to compare against, but the performance is now satisfactory for me.

This is obviously a workaround and not a solution, but I've not had any problems yet. Also, I don't know if this is what is affecting Mac users since their SystemInformation["Devices"] output seems to mention the Intel drivers already.

Sorry. I took a deep look. That option works with all other edges/lines but not Cylinder edges, which obviously is bug. I am expected this will be fixed in the next release. And before that, you can try to use the BSPTree rendering method which is located in Graphics Options/RenderingOptions, or you can set it like this:

Style[Graphics3D[...], RenderingOptions -> {"Graphics3DRenderingEngine" -> "BSPTree"}]

But this rendering method will slow things down a little though. Another possible solution is to define those edges explicitly.

I tried to turn it off, but with no success (I got exactly the same as without the option specification):

Is there anything else we can try? (10.4)

I'd like to see the pre-release program come back. I also have this particular problem, (Retina MacBook Pro with dedicated graphics.)

I set the option to auto-switch, but I think that the computer always uses the dedicated graphics with Mathematica.

I re-installed 10.3.1 until this issue is resolved. There is no problem (as noted by others) with 10.3.1.

Hi Yuzhu Lu, great to hear you tracked down the issue!

Is it also related to this line-drawing bug (from here)

or is this simply z-fighting?

I've never seen any negative correlation between pc speed and performance yet, so very interesting that this can happen!

So you're saying less is more... hmmm

I btw have the mid 2012 macbook pro retina (the very first retina notebook that came out).

I a bit too lazy to run this on all university machines and generate the report for all the laptops again, but the issue is universal on all of the machines.

Cheers,

Marco

PS:I'll add one or so more SystemReports to this.

They are all on the latest version of El Capitan.

Attachments:

Hi everyone,

I have tried this out on many different Macs now. I the latest, very highest spec MacBook Pro Retinas it works ok-ish (much worse than on 10.3.1 though), but on a highest spec MacBook the graphic takes 4 seconds or so to update. The MacBook has no issues on 10.3.1 at all with that graphic.

Cheers,

Marco

Also fast on Win 7, the cubes move around as fast as I can move the mouse.

Sander, we're looking into the problem and we can reproduce this in-house.

10.4 has a significantly overhauled OpenGL implementation which we expect will improve both the speed and quality of 3D graphics in upcoming releases. If there is a fix for this specific issue, we will work towards providing you and other customers an updated version.

In the mean time, please do provide the output from SystemInformation["Devices"]

Thank you for reporting this issue.

I assume you are talking about interactively dragging the Graphics3D object (rotating, etc.). I'm running 10.4 on Win 10. I don't see any slow down when dragging the cubes.

I can confirm this. I am also on OS X 10.11.3, late 2014 MacBook Pro retina.

The performance problem also affects the large mesh regions that I am working with at the moment. Example attached.

Attachments: