Problem applies to Rhino version 5A713 and all other versions I have 5A706, 5A701
Poor frame rates and lagging display regardless if its a new file or a file with complex geometry loaded. The window visibly jerks and stutters dragging the grid around.
This problem can be eliminated if you open any other osx window on top of rhino and then manipulate the window with out bringing rhino to the front. The pan and rotate in all windows is instantly smooth and almost lag free.
I am running both Imac 5k - (i7, 32gb ram, Radeon R9 m295x 4gb) and Macbook pro 2014 (i5 intergrated graphics) and have replcated this problem accross both machines. Both machine illustrate the same display refresh rates.
Ouch. Thanks for bringing this to our attention and for digging into the problem on two separate machines. I admit, I don’t have either of those machines to test with right now…and I can’t replicate this behavior on my MacBookPro (NVIDIA graphics). Can you please help me with a couple other pieces of information…
Can you post or e-mail me your software information for both the iMac 5k machine and the MBP 2014? You can find this in About Rhino > More info… button > Copy to Clipboard button. Then can you paste the information in a reply here, or in a PM, or e-mail to me (email@example.com)?
What exact steps can we use to replicate the slow graphics performance? I imagine it will be obvious when we test on the machines in question, but I don’t want to guess at all.
Ok after another go on the macbook pro I can say that the issue seems to
have resolved itself there and graphics performance is acceptable - smooth
panning and dragging of objects at all screen resolutions.
But the iMac the problem persists.
I would describe the problem as huge drop in frame rate when manipulating a
window with either dragging the gird/objects or moving across a window
using a active tool.
For a example of the issue if you drag the grid in a circular motion you
can see it freeze and stutter in a rhythmical pattern every other second -
so first second of movement smooth and the second second of continuos
movement the window will freeze and stutter.
For another example with an active tool you can see the crosshairs lagging
and jerking around behind the movement of your cursor.
I have also noticed this drop in frame rates also effects the dock if you
activate it whilst using a active tool (line tool for example). The dock
will exhibit stuttering and visible screen tearing of the icons as you move
I have noticed that if you grab a window next to the other viewports and
then move the cursor into another viewport whilst still manipulating the
other window the problem of lag and jerkyness is greatly reduced.
I can also say that using the same machine bootcamped running windows7 and
Rhino 5 there is no lag whats so ever and all viewports are silky smooth
even when manipulating complex models.
This problem is very distracting when using Rhino. I really hope we can
work out what is causing it. I will provide a video of this in action if it
would help also.
I don’t see a system report attached, but you mention other things that help pinpoint the issue.
This is the most troublesome part of your report. Rhino is not able to draw on or affect other parts of the computer display like the system Dock. Those portions of the display are managed by OS X.
If you are seeing visible effects in the system Dock then I believe you have GPU hardware problems. I would suggest that you take your iMac to an Apple Store and demonstrate exactly this Dock screen tearing and ask their opinion.
The dock tearing only happens when rhino has an active tool (with
crosshairs) and you stray over the dock. Its interesting that the tearing
displays the same tearing rhythm as the active rhino window. but for the
most part just disregard this information if it is not helpful.
Osx visual performance in all other programs and software (Modo, Maya,
Keyshot, Photoshop) is totally fine and very smooth. So I do not think that
it is a hardware issue.
I have no option for AnitAlias in rhino does this mean that all accelerated
gpu graphics are disabled?
I have modified the system report attachment to .pdf it was a .pages file
before maybe this was not supported.
From watching the crosshairs lag behind the cursor on a active tool I think
you can actually see the screen updating as you move it. I would gauge it
at around 5fps
I really hope the attached .pdf will shed dome light on what could be the
From your Rhino information report, I see you have changed your display resolution from the “Best for Display” setting in System Preferences > Displays to a higher value. This will impact your display performance. See http://wiki.mcneel.com/rhino/mac/retina. Please set your display resolution to Best for Display and retry your tests.
I still maintain that if you are seeing display tearing in the System Dock, then you have problems unrelated to Rhino. Rhino is unable to cause display tearing in other programs like the Dock.
Below is a link to a video without tool-palettes and changing display modes
as requested - the problem remains unchanged.
I did some searching regarding OpenGL and stuttering and found this page
detailing how problems using NStimer can result in screen lag and
stuttering as the clocks of the app and osx will drift out of sync - would
this explain the pattern to the lags and also why if another window is open
on top the problem disappears as OSX is then rendering the contents of the
So far you are the only person reporting this. We cannot duplicate this on any other Mac hardware. We do not have a retina iMac in house.
From what you are describing, this is only happening in very specific circumstances on one particular (very recent) Mac model. Rhino does not change how it draws to the display depending on the Mac model, nor does it change how it draws to the display depending on whether another window is on top of Rhino or not. If fact Rhino never knows when the latter case is in effect.
The stackoverflow post does not describe how Rhino does its drawing so isn’t really relevant here. Every 1/60 of a second, OS X asks Rhino to draw its viewports if they need redrawing. The stackoverflow article describes the opposite, which is commonly used in games, where the application decides when each frame should be drawn.
This looks to me like a bug in Apple’s display drivers on the retina iMac that does not handle certain conditions very well. The best we can do at this point is acquire a retina iMac, confirm that there is a problem, and then report it to Apple developers.
We’ve been talking with Apple engineers about this and we still don’t believe it is a problem with Rhino for Mac. One of the engineers ran a test on the new iMac 5k and could not reproduce the issue you are seeing. However, the Dock tearing issue was a bit of a concern and there’s something we would like you to try. Evidently, AutoCAD for Mac and Maya disable vsync (vertical syncing) and can occasionally introduce this problem. Are you running either of these softwares as well? If so, can I ask you to reboot, refrain from running these apps and try out Rhino for Mac again?
Yes I have rebooted my mac and the problem persists.
I have reset the SMC/PRAM too just for kicks and the problem persists.
I have also reinstalled the original Apple RAM (as I am running kingston
memory upgrade) and the problem persists.
Running bootcamped Windows7 and latest Rhino all windows are super smooth
and do not show any jerks or lags even with large files open.
Just to reiterate this is a dragging view problem with the window jerking
and lagging in a rhythmical fashion as if something was interfering with
the system at regular intervals (1 second approx).
Not sure if there is any correlation here with this previously resolved issue…
…but I would just add that the example model above is rather simplistic. I think the resolved retina MBP 11,3 issue would not have been exposed with this model either. One would need to introduce a somewhat “heavier” (though certainly “within bounds” IMO), model to expose the prior issue.
I have not yet had the opportunity to test the 5K iMac with MacRhino.